UUID · 2^122 for v4
UUID collision risk
Why 122 random bits is safe at scale, and when name-based IDs collide deliberately.
Key facts
| Random space | 2^122 for v4 |
|---|---|
| Birthday bound | About 2^61 values for a 50% chance |
| At 1 billion/sec | Centuries to reach the bound |
| Name-based | Deterministic repeats by design |
| Real risks | Weak RNG, truncation, duplicated namespaces |
The math in practice
Collision probability grows with the square of the number of values. With 122 random bits, generating a billion UUIDs per second for a century still leaves the chance vanishingly small. Hardware failure, duplicated databases and weak random sources are far more likely causes of duplicate keys.
Deliberate collisions
v3 and v5 produce the same UUID for the same namespace and name every time. That is a feature for stable IDs and a bug if you expected distinct records for repeated names. Always include a uniqueness constraint in the database rather than relying on the generator alone.
Frequently asked questions
Should I check the database for collisions?
Use a unique index. Retry on conflict if your generator or framework supports it; the check is cheap compared with silent duplicates.
Is Math.random() safe for UUIDs?
No. Use a cryptographic random source; some UUID libraries fall back to weak randomness in old environments.
Can truncating a UUID cause collisions?
Yes. Cutting bits reduces the space dramatically. Store the full 128 bits.