UUID v7 Collision Probability: The Real Numbers

The maths

v7 has 74 random bits, but two UUIDs can only collide if they share the same millisecond. So the question is how many ids you generate in one millisecond, not in total.

By the birthday bound over 2^74, a 50% collision chance needs about 1.6 × 10^11, roughly 160 billion, ids within that single millisecond. At a million ids per second you generate about a thousand per millisecond, which gives a collision probability of around 3 × 10^-17 for each millisecond. Sustained for a whole year, that still adds up to less than one in a million.

v4 has 122 random bits with no time partition and needs about 2^61 total ids for the same 50%. Different structure, and both are far outside anything real.

The 74-bit figure assumes a generator that fills everything after the timestamp with random bits. Implementations that guarantee ordering inside a millisecond spend part of that space on a counter: Python 3.14's uuid.uuid7() uses a 42-bit counter that starts at a random value each millisecond, plus 32 fresh random bits per UUID. Within one process the counter itself prevents duplicates; across processes the random counter start and tail keep the odds in the same astronomically small range.

Across distributed generators

Independent servers generating simultaneously all draw from the same 74-bit space for that millisecond, so the count is the total across the fleet.

Even at a hundred nodes generating ten thousand ids per second each, the per-millisecond count is around a thousand and the probability stays negligible. You would need an implausible rate before the arithmetic became interesting.

The failures that actually happen

A weak random source. A cloned virtual machine or container image with a copied entropy pool produces identical sequences on both instances — this is a real and recurring cause of duplicate ids.

A hand-rolled generator seeded from the clock. Two processes starting in the same millisecond generate the same values.

Clock rollback. An NTP correction moving time backwards makes a generator reuse a timestamp range, which breaks ordering and increases collision chances within the reused window.

What to do about it

Use the platform or a maintained library rather than writing the generator. Ensure /dev/urandom is seeded before an application starts on VMs and containers. Keep a unique constraint on the column — it costs nothing and turns an impossible event into a caught error rather than silent data corruption.

Frequently asked questions

Is v7 more collision-prone than v4?

It has fewer random bits, but they only need to be unique within one millisecond. Both are far beyond practical risk.

Do distributed generators increase the risk?

Only through the total rate per millisecond, which stays negligible at realistic volumes.

What actually causes duplicate UUIDs?

Bad entropy sources, clock-seeded generators and cloned VM images — never the probability.