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 2^37 — roughly 137 billion — ids within that single millisecond. At a million ids per second you generate about a thousand per millisecond, giving a collision probability around 10^-17.

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.

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.