UUID Collision Probability: What Are the Actual Odds?

Every few months, someone on my team asks: "What if two users get the same UUID?" It is a reasonable concern — the word "random" sounds risky when you are assigning primary keys to millions of users.

But the math behind UUID collision probability is worth understanding, because once you do, you will stop worrying about it permanently.

The Birthday Problem, Applied to UUIDs

The classic birthday problem asks: how many people do you need in a room for a 50% chance that two share a birthday? The answer is 23 — because with 365 possible birthdays, collisions happen faster than intuition suggests.

UUID v4 has 122 random bits. The formula for the expected number of collisions after generating N UUIDs is approximately:

collision_probability ≈ N² / (2 × 2^122)

To reach a 50% collision probability:

N² / (2 × 2^122) = 0.5
N² = 2^122
N = 2^61

That is 2.3 quintillion UUIDs — or 2.3 × 10^18.

I was using the DevFormatters UUID Generator the other day and wondering: even at 1 billion UUIDs generated per second, it would take roughly 73,000 years to hit a 50% collision chance.

This is the most frequently referenced number on Stack Overflow, where the UUID collision question has over 180,000 views and the top answer (1,800+ upvotes) does the same calculation.

Visualizing the Immensity

Numbers like 2^61 are hard to grasp. Here is a different way to think about it:

  • If you generated 1 million UUIDs per second for 100 years, you would have generated about 3.2 × 10^15 UUIDs.
  • The collision probability after 100 years at that rate is about 0.0000000001%.

Or put another way: you are about 800,000 times more likely to win the Powerball jackpot than to generate a duplicate UUID v4 in your lifetime.

A popular thread on r/programming about UUID collision math sums it up with the top comment: "Stop worrying about UUID collisions. Worry about your database connection pooling instead."

UUID v7 Changes the Calculation

UUID v7 has 74 random bits instead of 122 — nearly 50 bits fewer. Does that change the odds?

// UUID v4: 122 random bits
// UUID v7: 48 timestamp bits + 74 random bits

// With UUID v7, collisions are only possible within the same millisecond
// because the timestamp is unique across different milliseconds.

// Collision probability per millisecond:
// P(collision) ≈ N² / (2 × 2^74)
// With 10,000 UUIDs per millisecond:
// P = (10^4)² / (2 × 1.9 × 10^22) ≈ 2.6 × 10^(-15)

At 10,000 UUIDs per millisecond (10 million per second), you need about 5.8 billion UUIDs per millisecond for a 50% collision chance — which is not physically possible on current hardware.

Database Uniqueness Constraints

Even if the probability is astronomically low, what happens if a collision somehow occurs?

-- If a UUID collision happens, this constraint catches it
CREATE TABLE users (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL
);

-- Attempting to insert a duplicate UUID returns:
-- ERROR: duplicate key value violates unique constraint "users_pkey"

The database will reject the duplicate insert with a unique constraint violation. Your application needs to handle this error — not because it will happen in practice, but because having error handling for every database operation is good practice.

// Handle the theoretical UUID collision
try {
  await db.insert(user);
} catch (error) {
  if (error.code === '23505') { // PostgreSQL unique violation
    // Regenerate the UUID and retry once
    user.id = generateUUID();
    await db.insert(user);
  } else {
    throw error;
  }
}

When You Should Actually Worry

There are a few scenarios where UUID collision probability becomes a real concern:

  1. Using a weak random source. JavaScript's Math.random() is not cryptographically secure. If you generate UUIDs with Math.random(), the effective randomness is much lower than 122 bits. The Stack Overflow question about using Math.random() for UUIDs has 35,000 views. The answer is always no.

  2. Truncating UUIDs. Some systems store full UUIDs but use only the first N characters for display or reference. UUIDs that share a prefix are not collisions — but users may confuse them.

  3. Using a legacy UUID algorithm. UUID v1 uses MAC address + timestamp. If two machines have the same MAC address (rare in virtualized environments) and generate IDs at the same time, collisions are possible.

Related Searches

  • uuid collision probability
  • uuid birthday problem
  • how many uuids until collision
  • uuid v4 vs v7 collision
  • uuid random 122 bits
  • uuid collision probability calculator
  • uuid duplicate primary key
  • chance of two uuids being the same
  • uuid generation best practices
  • is uuid collision free

Frequently Asked Questions

What is the probability of a UUID v4 collision?

Effectively zero for any practical number of UUIDs. You need approximately 2.3 quintillion UUIDs for a 50% chance of any collision. At 1 billion UUIDs per second, that takes 73,000 years.

Does UUID v7 have a higher collision rate than v4?

UUID v7 has fewer random bits (74 vs 122), but collisions are only possible within the same millisecond. In practice, the collision rate is essentially zero for any real-world workload. You would need millions of UUIDs per millisecond to have a measurable collision chance.

What happens if a UUID collision occurs in a database?

The database's unique constraint rejects the duplicate insert with a duplicate key value error. Your application should handle this error gracefully — typically by regenerating the UUID and retrying. In practice, you will never trigger this error.

Can I use Math.random() to generate UUIDs?

No. Math.random() is not cryptographically secure. Use crypto.randomUUID() (Node.js/browser), uuid.v4() (JavaScript), or uuid.uuid4() (Python). The operating system's CSPRNG should always be the source of randomness for UUID generation.

How many UUIDs do I need to generate before I should worry?

At 1 trillion UUIDs, the collision probability is about 10^-13. At 1 quadrillion, it is about 10^-7. By the time you reach 1 quintillion IDs (which no system has ever done), the probability is about 10%. For any real-world application, UUID collision is not a risk worth considering.

Final Thoughts

UUID collision is one of those topics that sounds scary in theory but is completely harmless in practice. The 122-bit random space of UUID v4 is so vast that the probability of collision is dwarfed by the probability of hardware failure, cosmic ray bit flips, or even a developer accidentally dropping a production table.

Focus your energy on real database concerns: index tuning, query optimization, and connection management. UUID collision is not worth another minute of your team's time.