UUIDv4 Collision Risk: When Random IDs Are a Good Database Choice

Yes, UUIDv4 values can collide in principle. In normal application volumes, the chance is extraordinarily small because a version 4 UUID carries 122 random bits. That is a useful property, but it is not a substitute for a database uniqueness constraint or a plan for a duplicate-key error.

This guide answers the practical question: when is UUIDv4 a sensible identifier for a database record, and what safeguards should still be in place?

What makes a UUIDv4 different

A UUID is a 128-bit identifier written in a standard textual form. RFC 9562 defines version 4 as a randomly generated UUID. Six bits identify the UUID version and variant, leaving 122 bits for random or pseudorandom data. 1

That means a UUIDv4 is not a sequence number, a timestamp, or a proof of identity. It is an identifier whose usefulness comes from the very large space of possible values. A UUID generator is appropriate when an application needs to create identifiers without first asking one central counter for the next number.

yukt.tools includes a UUID-generation utility. Use it when you need an identifier for a test fixture, example payload, or manual workflow; let the application and database own identifiers used in production data paths.

How likely is a collision?

The answer depends on how many UUIDs are generated and whether the generator supplies genuinely independent random values. The usual approximation for at least one collision among n randomly selected values from a space of N values is:

P(collision) ≈ n² / (2N)

For UUIDv4, N is 2^122. At one billion generated UUIDs, this approximation is roughly 9.4 × 10^-20—far below ordinary operational risks such as an application bug, a bad migration, or a missing database constraint. The calculation is a probability estimate, not a guarantee that a collision cannot happen.

The randomness source matters. RFC 9562 says implementations should use a cryptographically secure pseudorandom number generator (CSPRNG) for UUIDv4, and it warns that weak random sources can make generated UUIDs predictable or create collisions. 1 1

Use a UUID as a key, but keep the constraint

A database primary key or unique index is still the final authority for uniqueness. The UUID generator works before a write; the database constraint verifies the result when the record is stored. Keeping both is simple and protects the data even if an unexpected duplicate, import error, or application defect occurs.

A practical write path looks like this:

1. Generate a UUID using the platform's supported CSPRNG-backed API.
2. Insert the record into a column protected by a primary-key or unique constraint.
3. If the insert reports a duplicate-key violation, generate a new ID and retry within a small, bounded policy.
4. Log or alert on such a failure so a sudden pattern can be investigated.

Do not use “the probability is tiny” as a reason to remove the constraint. The constraint also protects against duplicate values introduced by a restore, a test-data import, or code that accidentally reuses an identifier.

Choose UUIDv4 for the right reason

UUIDv4 is often a good fit when services need to create records independently, when exposing sequential IDs would be undesirable, or when a record may be created while disconnected and synchronized later. It avoids coordinating on a single incrementing counter before creating each ID.

It has tradeoffs too. UUIDv4 values are not ordered by creation time, so a UUID string cannot tell a reader when a record was made. Store a separate created-at timestamp when time ordering matters. Randomly distributed keys can also have different index and storage characteristics from monotonically increasing integer keys; measure the behavior in the specific database and workload rather than assuming one key type is universally faster.

If chronological ordering inside the identifier is an explicit requirement, review the UUID versions your platform supports. RFC 9562 defines version 7 as a time-ordered UUID based on a Unix timestamp plus random data, but choosing it is an application-design decision with its own privacy, ordering, and implementation considerations. 2

Avoid common UUID mistakes

• Do not treat a UUIDv4 as a secret. Randomness makes guessing harder than a counter, but authorization must still check whether the requester may access the referenced record.
• Do not infer creation order from UUIDv4 text. Keep an explicit timestamp and sort by the field that represents the event you mean to order.
• Do not silently convert an invalid UUID into a new one during an update. Reject or report malformed input so a client-side bug does not create an unintended record.
• Do not rely on a hand-written random-number routine. Use the UUID API documented for the language or runtime, and confirm its source of randomness where the platform documents it.
• Do not omit the unique constraint merely because IDs are generated outside the database.

A short decision checklist

Choose UUIDv4 when decentralized creation and a large random identifier space matter more than sortable keys. Before shipping, verify that the generator uses a suitable random source, the database column has a primary-key or unique constraint, duplicate-key handling is bounded and observable, and timestamps are stored separately where the product needs chronological order.

For a one-off UUID in a test or documentation example, use the UUID generator. For production records, generate the value inside the normal application path and let the database enforce uniqueness.

Frequently asked questions

Can two UUIDv4 values be the same?

Yes. A collision is mathematically possible because UUIDv4 selects values from a finite space. With 122 random bits, it is extremely unlikely at ordinary volumes when a suitable random source is used, but a database uniqueness constraint remains necessary. 1 1

Should UUIDv4 be a database primary key?

It can be. Make the column a primary key or otherwise enforce uniqueness, use the platform's supported UUID generator, and evaluate index and storage behavior with your actual database and workload. Keep a separate timestamp if the system needs a reliable creation-time order.

Is UUIDv4 sortable by time?

No. UUIDv4 is random rather than time-ordered. Store and query an explicit timestamp for chronological order. RFC 9562 specifies UUIDv7 for applications that need a time-ordered UUID design, but it should be chosen deliberately rather than as a drop-in assumption. 2

Sources and research

1. RFC 9562: Universally Unique IDentifiers (UUIDs) — IETF UUID specification, sections 5.4 and 6.9, accessed 2026-09-26.
2. RFC 9562: UUID Version 7 — IETF UUID specification, section 5.7, accessed 2026-09-26.