← Learnings

The Tale of the UUID

How something random became the world's favorite unique ID

★Universally unique — no matter who, no matter where

STARTUP · BERLIN

f47ac10b-58cc-4372…

BANK · TOKYO

9b1deb4d-3b7d-4bad…

PHONE · MID-ATLANTIC

3f333df6-90a4-4fda…

NO SHARED LIST · NO REGISTRY · NO PHONE CALL

Three systems that have never talked to each other — different companies, different continents, zero coordination — and their IDs still won't collide. Not "unique in my database." Universally unique. That's the part that sounds impossible… so let's see why it isn't.

01The old way breaks

Two databases both count 1, 2, 3… When you merge them — clash. Two rows think they're id 1. Auto-increment needs one boss handing out numbers.

02Enter the UUID

"Don't count. Just roll a gigantic dice and use whatever comes up!"

A UUID is 128 bits — 32 hex digits. Version 4 fills 122 of them with pure randomness (a couple bits are fixed markers: the 4 and the 8/9/a/b). No central counter. Any machine makes its own. Heads-up: this dashed text is just how it's shown — what's actually stored is 16 raw bytes (panel 11).

03128 bits on paper, 122 rolls of the dice

a1c8f3d2-9b4e-47a1-8e6f-2d5c9a0b1e3f

VERSION — 4 BITS FIXED VARIANT — 2 BITS FIXED

128 − 6 = 122TOTAL BITS − FIXED MARKERS = RANDOM BITS → 2¹²²

The string is always 128 bits wide — but 6 of them are hard-coded labels: 4 bits spell out "I'm version 4," and 2 bits mark the variant. They're identical on every v4 UUID, so they add nothing to uniqueness. Subtract them and you're left with 122 truly random bits — and 2¹²² is the number that actually decides collisions.

DEEP DIVE — WHAT DO THE VARIANT BITS SELECT?▾

The first digit N of the 4th group is a prefix code — read it first, and it tells you which layout rulebook applies.

FIRST DIGIT	TOP BITS	VARIANT — LAYOUT	STATUS
0 – 7	0xxx	Var 0 — NCS / Apollo	legacy, extinct
8 9 a b	10xx	Var 1 — RFC 4122 / 9562	the standard — what you use
c – d	110x	Var 2 — Microsoft GUID	legacy Windows/COM
e – f	111x	Var 3 — reserved	reserved for the future

The variant is a prefix code, like the lead bits in UTF-8: it uses only as many bits as it needs to stay unambiguous. Variant 1 grabbed the shortest free prefix (10), spending just 2 bits so the rest stays open for the version + randomness — the legacy variants "cost" 3 bits because they got longer prefixes. This is what makes a UUID self-describing: any parser reads these bits first to know the layout, so the format can keep evolving (v1 → v4 → v7 → v8…) without anyone ever needing to be told which rulebook applies.

1 · Peace between rival standards. UUIDs were invented three times — Apollo's NCS, Microsoft's GUID, and the OSF/RFC layout — and all three print as the same hex string but arrange their bytes differently. The variant tag says whose rulebook to read, so incompatible formats coexist in one bit-space with no central registry.

2 · Future-proofing. Variant 3 (111x → e/f) is left reserved on purpose — an escape hatch. If a genuinely new layout is ever needed, there's an unclaimed prefix waiting, and old parsers will at least see "a variant I don't understand" instead of silently misreading the fields.

Reality check: in practice almost everything today is Variant 1 — you'll basically never branch code on this. It's a fossil of UUID's messy multi-vendor history plus a little reserved headroom.

04How big is 2¹²²?

5,300,000,000,000,000,000,000,000,000,000,000,000≈ 5.3 × 10³⁶ POSSIBLE UUIDS

That's more IDs than there are grains of sand on Earth… squared. Roughly a trillion times the number of stars in the observable universe. The haystack is so vast that any two random needles almost never land in the same spot.

05The honest truth

Two random draws could match — physics allows it. UUIDs don't promise "impossible." They promise "so unlikely you can safely bet your whole system on it." This is the birthday paradox at planetary scale.

06Show me the odds

1,000,000,000 UUIDS / SECOND · FOR 100 YEARS

≈ 50 / 10¹⁸CHANCE OF EVEN ONE COLLISION

To reach a 50% chance of a single collision you'd need about 2.7 quintillion UUIDs (that's 2.7 × 10¹⁸). Nobody's databases are anywhere near that. You're more likely to be hit by a meteor mid-INSERT.

07Why we love them

No coordinator needed. Generate IDs offline, on a phone, in two data centers at once — then merge with zero clashes. That "good enough" randomness buys you freedom a central counter never could.

08Not always pure luck

V1 / V6 — HARDWARE + CLOCK

TIMESTAMP

MAC ADDRESS

SEQ

V4 — PURE DICE

122 RANDOM BITS

V7 — CLOCK + DICE

TIMESTAMP

RANDOMNESS

So it's not all luck. v1/v6 borrow uniqueness from real hardware + time; v4 is pure probability; v7 is a hybrid. Different versions, different bets.

09The real number

TOTAL UUIDS EVER MADE	CHANCE OF ANY COLLISION
1 billion	~1 in 10¹⁹
1 trillion	~1 in 11 trillion
1 quadrillion	~1 in 11 million
2.7 quintillion	≈ 50%
10 quintillion	≈ certain

Only one thing drives the risk: the grand total ever made — not timing, not how many machines. A trillion rows (≈1B/day for 3 years) still sits at 1-in-11-trillion. It only bites at physically absurd totals.

101 machine or 1,000?

Every UUID is an independent draw, so 1,000 machines at once = one machine doing the same total. The one real trap: cloned VMs with a duplicated random seed — then they're not independent. Fix: always use the OS crypto RNG.

11It's not really a string

WHAT YOU SEE — 36-CHAR TEXT

a1c8f3d2-9b4e-47a1-8e6f-2d5c9a0b1e3f

→

WHAT IT REALLY IS — 16 BYTES (128 BITS)

To you it looks like text — but a UUID is really 16 raw bytes. The dashes and letters are just a hex costume painted on top. Postgres stores the 16 bytes, not 36 characters. Anything that reads its version, pulls a timestamp, or ships it as binary is parsing those bytes — which is exactly why the byte layout (and that variant tag) has to be unambiguous.