[{"data":1,"prerenderedAt":866},["ShallowReactive",2],{"blog-uuid-v4-vs-v7":3},{"id":4,"title":5,"alt":6,"author":7,"body":8,"category":841,"description":842,"extension":843,"faq":844,"image":853,"meta":854,"navigation":712,"path":855,"publishedAt":856,"seo":857,"stem":858,"tags":859,"__hash__":865},"blog\u002Fen\u002Fuuid-v4-vs-v7.md","UUID v4 vs v7: When to Use Each (2026 Guide)","uuid v4 vs v7 — scattered random identifiers versus ordered time-sequenced identifiers","Alex Vibe, Senior Security Dev",{"type":9,"value":10,"toc":829},"minimark",[11,20,27,30,35,38,49,56,71,73,77,84,91,94,104,144,195,205,226,228,232,239,245,252,324,334,358,360,364,378,389,397,404,418,420,424,535,540,623,625,629,632,655,661,663,667,686,726,729,731,765,767,771,776,779,784,787,792,799,804,807,812,825],[12,13,14,15,19],"p",{},"Short version: ",[16,17,18],"strong",{},"UUID v4 is fully random, UUID v7 is time-ordered."," Use v7 for database primary keys because its sortable timestamp prefix keeps your indexes fast. Use v4 when you need an ID that leaks nothing and can't be guessed. Both are 128 bits, both are collision-safe at any realistic scale — they just optimize for opposite things.",[12,21,22,23,26],{},"v4 has been the default for a decade, and it's quietly murdering your database write performance. v7 was standardized in ",[16,24,25],{},"RFC 9562"," (May 2024) specifically to fix that. This guide breaks down the bit layout of each, the randomness math, why random keys wreck B-tree indexes, and a decision table you can paste into your architecture doc.",[28,29],"hr",{},[31,32,34],"h2",{"id":33},"the-128-bits-decoded","The 128 Bits, Decoded",[12,36,37],{},"Every UUID is 128 bits. The version determines how those bits are spent. Here's where they go:",[39,40,45],"pre",{"className":41,"code":43,"language":44},[42],"language-text","UUID v4  — 128 bits, 122 of them random\n┌──────────────────────────┬──────┬──────────────────────────┐\n│ random  (48 bits)        │ ver  │ random + variant         │\n│ ████████████████████████ │ 0100 │ ██ variant 10 ██████████ │\n└──────────────────────────┴──────┴──────────────────────────┘\n no time, no order — every bit is noise except 6 fixed ones\n\nUUID v7  — 128 bits, time-ordered\n┌────────────────────────┬──────┬────────┬──────┬────────────┐\n│ unix_ms timestamp (48) │ ver  │ rand 12│ var  │ random 62  │\n│ 1716800000000…         │ 0111 │ ▓▓▓▓   │  10  │ ██████████ │\n└────────────────────────┴──────┴────────┴──────┴────────────┘\n first 48 bits = creation time → sorts chronologically\n","text",[46,47,43],"code",{"__ignoreMap":48},"",[12,50,51,52,55],{},"The difference is entirely in the ",[16,53,54],{},"first 48 bits",". v4 fills them with noise. v7 fills them with a Unix timestamp in milliseconds, then pads the rest with randomness. That single design choice flips the identifier from \"scattered\" to \"sequential\" — and that's the whole ballgame for databases.",[12,57,58,59,62,63,66,67,70],{},"Both share 6 fixed bits: a 4-bit version field (",[46,60,61],{},"0100"," for v4, ",[46,64,65],{},"0111"," for v7) and a 2-bit variant field (",[46,68,69],{},"10","). Everything else is up for grabs.",[28,72],{},[31,74,76],{"id":75},"the-randomness-math-and-why-crack-tables-dont-apply","The Randomness Math (and Why Crack Tables Don't Apply)",[12,78,79,80,83],{},"A quick myth-bust: you don't \"brute-force\" a UUID the way you crack a password hash. There's no login prompt to hammer, so RTX 4090 guesses-per-second tables are the wrong lens. The metric that matters for UUIDs is ",[16,81,82],{},"collision probability"," — the odds that two independently generated IDs come out identical.",[12,85,86,87,90],{},"For ",[46,88,89],{},"b"," bits of randomness, the count of UUIDs needed for a 50% chance of a single collision follows the birthday bound:",[12,92,93],{},"$$n_{50%} \\approx 1.177 \\times \\sqrt{2^{b}}$$",[12,95,96,97,100,101,103],{},"Where ",[16,98,99],{},"n"," = number of UUIDs generated and ",[16,102,89],{}," = bits of randomness in the value.",[105,106,107,122],"ul",{},[108,109,110,113,114,117,118,121],"li",{},[16,111,112],{},"v4"," has ",[16,115,116],{},"122 random bits",": $\\sqrt{2^{122}} = 2^{61}$, so you'd need ~",[16,119,120],{},"2.7 × 10¹⁸"," UUIDs before a coin-flip collision. That's billions of IDs per second for over a century.",[108,123,124,113,127,130,131,135,136,139,140,143],{},[16,125,126],{},"v7",[16,128,129],{},"~74 random bits"," ",[132,133,134],"em",{},"per millisecond"," (the timestamp pins down the rest): $\\sqrt{2^{74}} = 2^{37}$, so you'd need ~",[16,137,138],{},"137 billion"," v7 UUIDs generated ",[132,141,142],{},"in the same millisecond"," to hit 50%. Also not happening.",[145,146,147,166],"table",{},[148,149,150],"thead",{},[151,152,153,157,160,163],"tr",{},[154,155,156],"th",{},"UUID",[154,158,159],{},"Random bits",[154,161,162],{},"UUIDs for 50% collision",[154,164,165],{},"Verdict",[167,168,169,183],"tbody",{},[151,170,171,174,177,180],{},[172,173,112],"td",{},[172,175,176],{},"122",[172,178,179],{},"~2.7 × 10¹⁸",[172,181,182],{},"Collision-free in practice",[151,184,185,187,190,193],{},[172,186,126],{},[172,188,189],{},"~74 (per ms)",[172,191,192],{},"~137 billion \u002F ms",[172,194,182],{},[12,196,197,200,201,204],{},[16,198,199],{},"Both are safe."," v7's lower entropy is a non-issue because collisions only matter ",[132,202,203],{},"within the same millisecond bucket"," — and 74 bits there is overkill.",[12,206,207,208,211,212,215,216,219,220,225],{},"One caveat that ",[132,209,210],{},"is"," about randomness: the random bits must come from a real CSPRNG. Avoid any library that builds UUIDs with ",[46,213,214],{},"Math.random()"," — it's a predictable PRNG with a seedable state, so its \"random\" segments can be reconstructed. The browser-native ",[46,217,218],{},"crypto.randomUUID()"," uses ",[16,221,222],{},[46,223,224],{},"crypto.getRandomValues()"," under the hood, the same OS-level entropy your kernel uses. That's the standard you want.",[28,227],{},[31,229,231],{"id":230},"why-v4-wrecks-your-database-index","Why v4 Wrecks Your Database Index",[12,233,234,235,238],{},"Here's the problem nobody warns you about until your write latency spikes in production. Database primary keys live in a ",[16,236,237],{},"B-tree index",", and B-trees love sequential inserts. A random v4 key lands in a random leaf page every single time:",[39,240,243],{"className":241,"code":242,"language":44},[42],"v4 — a random key lands mid-page, so a full page splits in two\n   ┌───────────────┐                   ┌─────────┐  ┌───────┐\n   │ page: 3 5 8 9 │  + insert 6   →    │ 3 5 6   │  │ 8 9   │   ◄ SPLIT\n   └───────────────┘                   └─────────┘  └───────┘\n   …and this repeats for nearly every insert, all over the tree\n\nv7 — a time-ordered key always lands at the right edge, no split\n   ┌────────────────┐                  ┌────────────────┐\n   │ page: …97 98   │  + insert 99  →   │ …97 98 99      │   ◄ just appends\n   └────────────────┘                  └────────────────┘\n   pages fill densely, writes stay sequential, the hot page stays cached\n",[46,244,242],{"__ignoreMap":48},[12,246,247,248,251],{},"With v4, each insert can dirty a cold page anywhere in the tree, forcing a read-modify-write and frequent ",[16,249,250],{},"page splits"," as full pages get torn in half to make room. The result is index fragmentation, poor buffer-pool cache locality, and write amplification that gets worse as the table grows.",[145,253,254,267],{},[148,255,256],{},[151,257,258,261,264],{},[154,259,260],{},"Index behavior",[154,262,263],{},"v4 (random)",[154,265,266],{},"v7 (time-ordered)",[167,268,269,280,291,302,313],{},[151,270,271,274,277],{},[172,272,273],{},"Where each row lands",[172,275,276],{},"A random leaf page",[172,278,279],{},"The rightmost (newest) page",[151,281,282,285,288],{},[172,283,284],{},"Page splits",[172,286,287],{},"Frequent",[172,289,290],{},"Rare",[151,292,293,296,299],{},[172,294,295],{},"Index fragmentation",[172,297,298],{},"High",[172,300,301],{},"Low",[151,303,304,307,310],{},[172,305,306],{},"Buffer-pool cache hits",[172,308,309],{},"Poor — cold pages",[172,311,312],{},"High — hot page reused",[151,314,315,318,321],{},[172,316,317],{},"Write amplification",[172,319,320],{},"High, worsens as the table grows",[172,322,323],{},"Minimal",[12,325,326,327,330,331,333],{},"This hurts most in ",[16,328,329],{},"clustered-index"," engines, where the primary key ",[132,332,210],{}," the physical row order:",[105,335,336,342,352],{},[108,337,338,341],{},[16,339,340],{},"MySQL InnoDB"," — the clustered PK dictates on-disk layout. Random v4 keys are a worst-case scenario; v7 is a massive win.",[108,343,344,347,348,351],{},[16,345,346],{},"SQL Server"," — clusters on the PK by default. v7 is the cross-platform answer to the old ",[46,349,350],{},"NEWSEQUENTIALID()"," trick.",[108,353,354,357],{},[16,355,356],{},"PostgreSQL"," — heap-organized, so the PK is a secondary index. The pain is milder, but v7 still improves index locality and cache hit rates.",[28,359],{},[31,361,363],{"id":362},"v7-to-the-rescue-with-one-catch","v7 to the Rescue — With One Catch",[12,365,366,367,370,371,373,374,377],{},"UUID v7 gives you the universal-uniqueness of a UUID ",[132,368,369],{},"and"," the insert-friendliness of an auto-increment integer. Because the high 48 bits are a timestamp, lexicographic sort order equals chronological order — you get \"created at\" for free, and inserts stay sequential. Most languages now ship a v7 generator, and recent ",[16,372,356],{}," versions support ",[46,375,376],{},"uuidv7()"," natively.",[12,379,380,381,384,385,388],{},"The catch: ",[16,382,383],{},"v7 leaks the creation time."," Anyone holding the ID can read the embedded millisecond timestamp and know exactly when the record was created. They can also ",[132,386,387],{},"predict"," the high bits of IDs created around the same time. That's fine for an internal primary key. It's a problem for a public, guessable identifier:",[105,390,391,394],{},[108,392,393],{},"Don't use v7 in a capability URL (a \"secret link\") — the timestamp narrows the guess space and reveals metadata.",[108,395,396],{},"Don't use v7 where creation-time disclosure is sensitive (medical records, financial events, anything you'd redact in a log).",[12,398,399,400,403],{},"For those cases, v4's wall of noise is the feature. And for genuine secrets — API keys, session tokens, signing secrets — ",[16,401,402],{},"neither version is the right tool."," A UUID maxes out at 122 random bits; a dedicated secret generator gives you 256 bits or more with no structure to leak.",[12,405,406,407,414,415,417],{},"If you just need solid, RFC-compliant v4 UUIDs right now, generate them with our ",[16,408,409],{},[410,411,413],"a",{"href":412},"\u002Fuuid-generator","UUID Generator"," — runs 100% in your browser, zero data sent to any server — which produces them via ",[46,416,218],{},". Zero-Knowledge: the UUID Generator processes everything in your browser's volatile memory. Nothing is ever transmitted to a server. It also does bulk generation up to 500 at once if you're seeding a dataset.",[28,419],{},[31,421,423],{"id":422},"v4-vs-v7-the-full-comparison","v4 vs v7: The Full Comparison",[145,425,426,439],{},[148,427,428],{},[151,429,430,433,436],{},[154,431,432],{},"Property",[154,434,435],{},"UUID v4",[154,437,438],{},"UUID v7",[167,440,441,451,460,471,482,493,503,513,524],{},[151,442,443,446,449],{},[172,444,445],{},"Total bits",[172,447,448],{},"128",[172,450,448],{},[151,452,453,455,457],{},[172,454,159],{},[172,456,176],{},[172,458,459],{},"~74",[151,461,462,465,468],{},[172,463,464],{},"Time component",[172,466,467],{},"None",[172,469,470],{},"48-bit Unix-ms timestamp",[151,472,473,476,479],{},[172,474,475],{},"Sortable by creation",[172,477,478],{},"No",[172,480,481],{},"Yes (lexicographic = chronological)",[151,483,484,487,490],{},[172,485,486],{},"DB index locality",[172,488,489],{},"Poor (random scatter)",[172,491,492],{},"Excellent (sequential append)",[151,494,495,498,500],{},[172,496,497],{},"Leaks creation time",[172,499,478],{},[172,501,502],{},"Yes",[151,504,505,508,510],{},[172,506,507],{},"Predictable \u002F enumerable",[172,509,478],{},[172,511,512],{},"Partially (timestamp prefix)",[151,514,515,518,521],{},[172,516,517],{},"Standardized in",[172,519,520],{},"RFC 4122 \u002F 9562",[172,522,523],{},"RFC 9562 (2024)",[151,525,526,529,532],{},[172,527,528],{},"Best for",[172,530,531],{},"Public IDs, tokens, unpredictability",[172,533,534],{},"Database primary keys",[536,537,539],"h3",{"id":538},"pick-by-use-case","Pick by use case",[145,541,542,552],{},[148,543,544],{},[151,545,546,549],{},[154,547,548],{},"Your situation",[154,550,551],{},"Use",[167,553,554,563,572,581,590,603,612],{},[151,555,556,559],{},[172,557,558],{},"Primary key in MySQL InnoDB \u002F any clustered index",[172,560,561],{},[16,562,126],{},[151,564,565,568],{},[172,566,567],{},"High-insert-rate table, want natural time ordering",[172,569,570],{},[16,571,126],{},[151,573,574,577],{},[172,575,576],{},"Replacing an auto-increment INT primary key",[172,578,579],{},[16,580,126],{},[151,582,583,586],{},[172,584,585],{},"Public-facing ID that must not be enumerable",[172,587,588],{},[16,589,112],{},[151,591,592,599],{},[172,593,594,595,598],{},"Must not leak ",[132,596,597],{},"when"," a record was created",[172,600,601],{},[16,602,112],{},[151,604,605,608],{},[172,606,607],{},"Distributed client-side IDs, order irrelevant",[172,609,610],{},[16,611,112],{},[151,613,614,617],{},[172,615,616],{},"Security token, capability URL, or API secret",[172,618,619,622],{},[16,620,621],{},"Neither"," — use a dedicated secret generator",[28,624],{},[31,626,628],{"id":627},"what-about-v1-v6-and-v8","What About v1, v6, and v8?",[12,630,631],{},"RFC 9562 (which obsoleted the old RFC 4122) blesses a few more versions you'll bump into:",[105,633,634,640,649],{},[108,635,636,639],{},[16,637,638],{},"v1"," — timestamp + the machine's MAC address. Time-ordered, but it leaks your hardware identifier and the timestamp is awkwardly byte-ordered for sorting. Superseded by v7 for new work.",[108,641,642,645,646,648],{},[16,643,644],{},"v6"," — a field-reordered v1 that ",[132,647,210],{}," sortable. A reasonable migration target if you're already on v1, but v7 is the cleaner choice for greenfield systems.",[108,650,651,654],{},[16,652,653],{},"v8"," — an explicitly \"custom\" version: the spec hands you the bits and lets you define the layout. For when you need to embed your own structured data and accept the responsibility.",[12,656,657,658],{},"For 99% of new systems the decision is binary: ",[16,659,660],{},"v7 for keys, v4 for everything that must stay opaque.",[28,662],{},[31,664,666],{"id":665},"storage-implementation-notes","Storage & Implementation Notes",[12,668,669,670,673,674,679,680,685],{},"A UUID is 16 bytes. Stored as the canonical 36-character string (",[46,671,672],{},"CHAR(36)","), it balloons to more than double the size and slows every index comparison. Store it as ",[16,675,676],{},[46,677,678],{},"BINARY(16)"," (MySQL) or the native ",[16,681,682],{},[46,683,684],{},"uuid"," type (PostgreSQL) — smaller pages, faster comparisons, denser indexes.",[39,687,691],{"className":688,"code":689,"language":690,"meta":48,"style":48},"language-sql shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","-- MySQL: store the 16 raw bytes, not the 36-char string\nid BINARY(16) PRIMARY KEY\n\n-- PostgreSQL: native uuid type + uuidv7() on recent versions\nid uuid PRIMARY KEY DEFAULT uuidv7()\n","sql",[46,692,693,701,707,714,720],{"__ignoreMap":48},[694,695,698],"span",{"class":696,"line":697},"line",1,[694,699,700],{},"-- MySQL: store the 16 raw bytes, not the 36-char string\n",[694,702,704],{"class":696,"line":703},2,[694,705,706],{},"id BINARY(16) PRIMARY KEY\n",[694,708,710],{"class":696,"line":709},3,[694,711,713],{"emptyLinePlaceholder":712},true,"\n",[694,715,717],{"class":696,"line":716},4,[694,718,719],{},"-- PostgreSQL: native uuid type + uuidv7() on recent versions\n",[694,721,723],{"class":696,"line":722},5,[694,724,725],{},"id uuid PRIMARY KEY DEFAULT uuidv7()\n",[12,727,728],{},"If you're stuck on v4 keys in a legacy InnoDB table and can't migrate, the classic mitigation is to reorder the timestamp bytes to the front — but that's literally reinventing v7. Just adopt v7.",[28,730],{},[732,733,734,739,742],"blockquote",{},[12,735,736],{},[16,737,738],{},"🛡️ Security Checkpoint — Complete This Step",[12,740,741],{},"A UUID is an identifier, not a secret — and using the wrong version (or treating one as a password) is how IDs become enumerable and keys become guessable.",[105,743,744,751,758],{},[108,745,746,747,750],{},"→ ",[410,748,749],{"href":412},"Generate cryptographically secure v4 UUIDs"," — RFC-compliant, bulk up to 500, all client-side",[108,752,746,753,757],{},[410,754,756],{"href":755},"\u002Fsecret-key-generator","Generate real security tokens and keys"," — 256-bit+ secrets for the jobs a UUID should never do",[108,759,746,760,764],{},[410,761,763],{"href":762},"\u002Fpassword-strength-checker","Audit the strength of any token"," — confirm a secret has the entropy you think it does",[28,766],{},[31,768,770],{"id":769},"frequently-asked-questions","Frequently Asked Questions",[12,772,773],{},[16,774,775],{},"What's the difference between UUID v4 and v7?",[12,777,778],{},"UUID v4 is 122 bits of pure randomness — fully unpredictable, but generated in no particular order. UUID v7 spends its first 48 bits on a Unix-millisecond timestamp and fills the remaining ~74 bits with randomness. That timestamp prefix makes v7 sort chronologically and behave like a sequential key in a database index. The trade-off: v7 has less entropy and openly reveals when each ID was created. Both are 128 bits total and both are collision-safe at any realistic volume.",[12,780,781],{},[16,782,783],{},"Should I use UUID v4 or v7 for a database primary key?",[12,785,786],{},"Use v7. Random v4 keys scatter inserts across the whole B-tree, causing page splits, fragmentation, and cache misses — a documented performance killer in clustered-index engines like MySQL InnoDB and SQL Server. v7's time-ordered prefix makes inserts append to the rightmost page, keeping the index dense and the hot page in cache. PostgreSQL's heap storage softens the v4 penalty, but v7 still wins on index locality.",[12,788,789],{},[16,790,791],{},"Is UUID v7 safe to use as a security token?",[12,793,794,795,798],{},"No. v7 embeds a readable creation timestamp and its high bits are predictable for IDs made around the same time, so it's partially enumerable. For unpredictable public identifiers use v4's 122 random bits. For actual secrets — API keys, session tokens, signing keys — don't use any UUID; reach for a dedicated ",[410,796,797],{"href":755},"secret key generator"," that gives you 256 bits or more with no exploitable structure.",[12,800,801],{},[16,802,803],{},"Does UUID v7 replace v4?",[12,805,806],{},"No — they solve different problems. v7 is the better default for database primary keys and any place you want natural time ordering. v4 remains correct whenever maximum unpredictability and zero metadata leakage matter, such as public resource IDs you don't want anyone enumerating or timing. Many systems use both: v7 internally for keys, v4 for externally exposed identifiers.",[12,808,809],{},[16,810,811],{},"Are UUID collisions something I need to worry about?",[12,813,814,815,818,819,821,822,824],{},"Practically never. v4's 122 random bits mean you'd need on the order of 2.6 × 10¹⁸ UUIDs for a 50% chance of a single collision. v7 keeps ~74 random bits ",[132,816,817],{},"within each millisecond",", which would require roughly 137 billion IDs generated in that same millisecond to collide. The one real requirement is that the random bits come from a CSPRNG like ",[46,820,224],{}," — never from ",[46,823,214],{},", whose predictable state defeats the math entirely.",[826,827,828],"style",{},"html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":48,"searchDepth":703,"depth":703,"links":830},[831,832,833,834,835,838,839,840],{"id":33,"depth":703,"text":34},{"id":75,"depth":703,"text":76},{"id":230,"depth":703,"text":231},{"id":362,"depth":703,"text":363},{"id":422,"depth":703,"text":423,"children":836},[837],{"id":538,"depth":709,"text":539},{"id":627,"depth":703,"text":628},{"id":665,"depth":703,"text":666},{"id":769,"depth":703,"text":770},"Security","UUID v4 is fully random; v7 is time-ordered for fast database indexes. Here's the bit-level breakdown, the trade-offs, and which to pick. Generate yours free.","md",[845,847,849,851],{"question":775,"answer":846},"UUID v4 is 122 random bits — fully unpredictable but in random order. UUID v7 prepends a 48-bit Unix-millisecond timestamp, so it sorts chronologically and behaves far better as a database key. v7 trades ~48 bits of randomness for index performance and leaks the creation time.",{"question":783,"answer":848},"Use v7. Its time-ordered prefix means inserts append sequentially, avoiding the B-tree page splits and fragmentation that random v4 keys cause — especially painful in clustered indexes like MySQL InnoDB.",{"question":791,"answer":850},"No. v7's timestamp prefix is predictable and reveals when the record was created, making IDs enumerable. Use v4 (122 random bits) for unpredictable public IDs, and a dedicated secret generator for actual security tokens.",{"question":803,"answer":852},"No. v7 is the better default for database primary keys; v4 stays the right choice when you need maximum unpredictability and zero metadata leakage, such as public-facing resource IDs.","\u002Fimages\u002Fblog\u002Fuuid-v4-vs-v7\u002Fhero.webp",{},"\u002Fen\u002Fuuid-v4-vs-v7","2026-05-27",{"title":5,"description":842},"en\u002Fuuid-v4-vs-v7",[860,861,862,863,864],"uuid v4 vs v7","uuid generator","database primary key","rfc 9562","time-ordered uuid","UDSFNrmdwFYF_rK5rKt5RFeiY6nQKqaQXUOjULnp9Gk",1782717487698]