UUID-v4 Cluster Collision Probability
UUIDv4: 122 random bits. You need 2.71×10¹⁸ UUIDs for 50% collision probability. At 1 billion generated per second: 85 years. The Y2K of distributed systems — every DBA worries about it, nobody has actually seen a collision in production. Apply the birthday paradox formula and quantify the risk at your scale.
🔑 Key Generation Volume
Enter UUID v4 count in billions. The engine computes collision probability via birthday paradox, safe threshold at 10⁻⁹ risk, and the number of UUIDs that fit before hitting 1%, 10%, 50% collision probability.
UUID v4 Collision: 100 Billion Keys = 10⁻¹³ Probability
UUID version 4 (RFC 9562, formerly RFC 4122) generates identifiers from 122 random bits — 6 bits are reserved for the version (0100) and variant (10) fields, leaving 122 bits of cryptographic-quality randomness. The resulting identifier space contains 2¹²² ≈ 5.3 × 10³⁶ possible values. To put this in perspective: generating 1 billion UUIDs per second for 100 years would produce roughly 3 × 10¹⁸ keys — still 18 orders of magnitude below the space size. Collisions at any realistic scale are astronomically improbable.
The Birthday Paradox Formula for UUID Collision
The collision probability for n randomly generated items from a space of size d is approximated by the birthday paradox formula: p ≈ n² / (2d) for n ≪ d. For UUID v4, d = 2¹²² ≈ 5.3 × 10³⁶. This means:
| UUIDs Generated | n² / (2 × 2¹²²) | Approximate Collision Probability | Interpretation |
|---|---|---|---|
| 1 billion (10⁹) | 10¹⁸ / 1.06×10³⁷ | ~10⁻¹⁹ | Effectively impossible |
| 1 trillion (10¹²) | 10²⁴ / 1.06×10³⁷ | ~10⁻¹³ | Still astronomically unlikely |
| 1 quadrillion (10¹⁵) | 10³⁰ / 1.06×10³⁷ | ~10⁻⁷ | 1 in 10 million — approaching concern |
| 2.71 × 10¹⁸ | 1 | ~50% | 50% collision probability threshold (√(2d)) |
122 Random Bits: Why UUID v4 Is Safe at Any Scale
UUID v4 dedicates 122 of its 128 bits to randomness. The remaining 6 bits are structural: 4 bits for the version identifier (binary 0100 = version 4) and 2 bits for the RFC 9562 variant (binary 10). This is a deliberate design choice that preserves interoperability while maximizing the entropy pool. The 50% collision threshold — reached when n ≈ √(2d) = √(2 × 2¹²²) ≈ 2.7 × 10¹⁸ — requires generating over 2.7 quintillion UUIDs. Even at 1 billion keys per second, this would take over 85 years of continuous generation.
When to Worry About Collisions
The real-world collision risk for UUID v4 comes not from the randomness but from flawed random number generators (RNGs). A poorly seeded PRNG, a virtual machine cloned with identical entropy state, or a containerized application with insufficient entropy pool can produce duplicate UUIDs far more frequently than the mathematical model predicts. Production systems should use cryptographically secure PRNGs (CSPRNGs) like /dev/urandom on Linux, crypto.randomUUID() in modern browsers and Node.js, or java.util.UUID.randomUUID() which delegates to SecureRandom — all of which use OS-level entropy sources. If your UUID generation depends on Math.random(), collisions are your smallest concern.
📖 Read the full analysis: UUID v4 Collision Probability at Scale: How Many UUIDs Before a Collision? — a 13-minute deep-dive covering the birthday paradox math at real distributed-system scales, UUID version comparison (v1 vs v4 vs v7), production collision case studies, and a practical decision framework for choosing and deploying UUIDs safely.