Are UUIDs Really Unique? Collision Probability Explained with Real Numbers

Every developer eventually asks it: if UUIDs are just random numbers, two of them could be the same — so why does everyone act as if they never are? The honest answer is that collisions are possible but so improbable that worrying about them is like worrying that all the air molecules in your room will spontaneously gather in one corner. This article makes that claim tangible: the size of the 2^122 space, the birthday-paradox math, concrete numbers you can repeat in a design review, and — importantly — the real-world failure modes that do produce duplicate UUIDs.

How Big Is 2^122, Really?

A version 4 UUID has 128 bits, of which 6 are fixed metadata (version and variant), leaving 122 bits of pure randomness. That gives:

2^122 = 5,316,911,983,139,663,491,615,228,241,121,378,304
      ≈ 5.3 × 10^36  (5.3 undecillion)

For scale:
  Grains of sand on Earth        ~ 7.5 × 10^18
  Stars in the observable universe ~ 10^24
  UUID v4 space                    ~ 5.3 × 10^36

If every one of Earth's 8 billion people generated one million UUIDs every second, it would take over 21,000 years just to produce as many UUIDs as there are stars in the observable universe — and that count would still be a trillion times smaller than the UUID space. Exhausting the space is not the risk, though. The real question is subtler: how many UUIDs can exist before two of them anywhere happen to match?

The Birthday Paradox, Applied to UUIDs

Collisions follow birthday-paradox math: with 23 people in a room, there is already a 50% chance two share a birthday, because every pair is a chance to collide. The same effect means UUID collisions become likely long before you generate 2^122 of them — at roughly the square root of the space, about 2^61 generations. The standard approximation for n random values in a space of d:

P(collision) ≈ 1 - e^(-n² / 2d)      where d = 2^122

n (UUIDs generated)     | P(at least one collision)
------------------------|---------------------------
1 billion   (10^9)      | ~1 × 10^-19
1 trillion  (10^12)     | ~1 × 10^-13
103 trillion            | ~1 × 10^-9   (one in a billion)
2.6 × 10^18 (2^61.2)    | ~50%

Read that middle row again: you can generate 103 trillion UUIDs — thousands per human on Earth — and the chance of even one duplicate among all of them is one in a billion. That is the number worth memorising.

Making It Concrete: Billions per Second, for Centuries

Suppose you run an absurdly hot system that mints one billion UUIDs per second, continuously:

• After one year (~3.2 × 10^16 UUIDs), collision probability is about 10^-4 — one in ten thousand — and that is already a workload thousands of times beyond any real company.
• To reach a 50% chance of a single collision, you would need to keep that pace up for roughly 86 years.
• A realistic large system — say 10 million IDs per day for 30 years (~10^11 total) — has a collision probability around 10^-15, thousands of times less likely than being struck by lightning this year.

For comparison, the uncorrectable bit-error rate of enterprise storage is around 10^-16 per bit read. Long before a UUID collision corrupts your data, ordinary hardware will have done it first. This is why the engineering consensus is to treat v4 UUIDs as unique by construction.

What Actually Causes Duplicate UUIDs

Real duplicates do occur — but essentially never from fair dice rolling the same number twice. Documented causes are always implementation or human failures:

• Bad or non-cryptographic RNGs — old code using Math.random()-style generators with tiny internal state can repeat outputs. Always use crypto-grade sources like crypto.randomUUID() or Python's uuid4().
• Seeded generators — a PRNG seeded with a constant (or with low-entropy input like the current second) produces the same "random" UUID sequence on every run and on every machine.
• Cloned VMs and containers — snapshot a machine, restore it twice, and both copies may resume with identical RNG state and emit identical UUIDs until reseeded. Forked processes can share entropy the same way.
• Copy-paste — the most common cause by far: an example UUID hard-coded in a tutorial, config template, or fixture gets pasted into ten services. Certain well-known UUIDs appear in thousands of unrelated databases.
• Truncation — chopping a UUID to its first 8 characters for a "short ID" shrinks the space from 2^122 to 2^32, where collisions appear after only ~77,000 values.

Notice the pattern: every failure mode removes the randomness. Keep the full 122 random bits from a secure source and the math holds.

Why v4 Generators Never Check for Uniqueness

A uniqueness check would require a registry of every UUID ever generated, shared by every machine on Earth — which is precisely the central authority UUIDs exist to eliminate. The design bet is that 122 bits of entropy make coordination unnecessary, and the numbers above show the bet is safe by dozens of orders of magnitude.

The pragmatic engineering stance:

• Do not pre-check UUIDs for uniqueness before insert — it is wasted latency guarding against a 10^-19 event.
• Do declare the column PRIMARY KEY or UNIQUE — the database enforces uniqueness for free, so even the impossible case becomes a clean, retryable insert error instead of silent corruption.
• Do use a cryptographically secure generator and never truncate.

Want to see the randomness in action? Generate a few hundred UUIDs with the free UUID generator — every one will differ, and now you know exactly why that never surprises anyone.

Frequently Asked Questions