How UUIDs Work: Versions, Collisions, and Database Keys

A UUID is a 128-bit identifier designed to distinguish an object from other objects without relying on one central numbering service. The two versions commonly considered for new applications are v4, which is random, and v7, which includes a timestamp and is arranged for time-based sorting. Knowing their differences helps you choose an identifier that fits your database and privacy needs.

What a UUID contains

UUID stands for Universally Unique Identifier. The current specification is RFC 9562. A UUID is 128 bits long, regardless of its version. Its version determines how some of those bits are assigned and what the remaining fields represent.

The familiar text format has 32 hexadecimal digits grouped into five parts, separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Each x represents a hexadecimal digit. The M position identifies the version, and the high bits represented by N identify the UUID variant. A v4 UUID, for example, looks like this:

550e8400-e29b-41d4-a716-446655440000

The hyphens are a readable representation; they are not extra data. UUIDs are commonly shown as hexadecimal text, but systems may store the same 128 bits in a native UUID type or binary form. Use a UUID generator when you need a ready-to-use identifier.

UUID v4: random identifiers

UUID v4 is generated from random or pseudorandom data. Its version and variant bits have fixed meanings, leaving 122 bits for random values. A well-implemented generator uses a suitable random source; the identifier should not be made by simply choosing arbitrary characters or using a predictable counter.

Because v4 values do not encode a sequence or timestamp, they are useful when identifiers should be created independently by different services or devices. They are also less revealing than time-based identifiers: a v4 value does not directly disclose when it was generated.

Random UUIDs do not guarantee that a duplicate is mathematically impossible. Instead, the number of possible values is so large that the chance of a collision is very small when generation is sound. For n independently generated v4 UUIDs, the birthday approximation for collision probability is about n(n − 1) / 2^123, while the probability remains small. This approximation assumes the random bits are distributed uniformly; a weak or faulty random generator can undermine it.

UUID v7: time-ordered identifiers

UUID v7 places a 48-bit Unix timestamp, measured in milliseconds, at the beginning of the UUID. The remaining bits include the version and variant markers and 74 bits available for random data, counters, or a combination, depending on the generation method.

Since the timestamp comes first, v7 UUIDs are designed to sort roughly by creation time when compared in their standard byte order. This can help databases that store and index records as they arrive: newer identifiers tend to be near one another in key order rather than scattered throughout the index as random v4 values can be. The exact benefit depends on the database, its UUID representation, and its index implementation.

Time ordering is not the same as a guaranteed global sequence. Two UUIDs generated in the same millisecond may not sort in the order they were created, especially if their remaining bits are random. Clock differences between machines, clock adjustments, and a generator's counter strategy also affect ordering. If strict ordering is required, use a sequence or ordering mechanism designed for that purpose rather than assuming UUID v7 provides one.

The timestamp is visible in a v7 UUID. That can reveal an approximate creation time, so consider whether that information is acceptable before exposing v7 values publicly. A Unix timestamp converter can help make sense of time values when working with timestamps, though a UUID's timestamp field must first be extracted according to its format.

Collision risk in practice

A collision happens when two separate generation events produce the same UUID. With v4, the probability follows the birthday effect: as more values are created, the chance rises, but it remains extremely low for ordinary application-scale use when the generator is reliable. It is not correct to say collisions are impossible.

For v7, the timestamp reduces the range of possible values for identifiers created in the same millisecond. If the 74 available bits are independently random within a given millisecond, the approximate collision probability for m UUIDs generated in that millisecond is m(m − 1) / 2^75. Actual generators may use counters or other strategies, so the precise behavior depends on their implementation. The TIG UUID generator, for example, uses a 12-bit counter for v7 UUIDs created in the same millisecond (the method in RFC 9562, section 6.2), leaving 62 random bits, so a batch it creates sorts in creation order.

Applications should still enforce uniqueness in storage. A primary-key or unique constraint catches duplicates rather than relying only on probability. If a conflict occurs, the application can generate another identifier and retry where appropriate. UUIDs also do not prove that a record is authentic, secret, or authorized: access control must be handled separately.

UUIDs as database keys

UUIDs are useful as primary keys when records may be created by multiple services, on separate machines, or while offline. Each system can generate an identifier locally, then exchange records without first asking a central service for the next number. UUIDs also avoid exposing a simple count of records, although they should not be treated as a security boundary.

There are trade-offs. A UUID is larger than a 32-bit or 64-bit integer key, and indexes on UUIDs can take more space. Random v4 values may be inserted at varied positions in a tree-based index, which can lead to less sequential index activity than time-ordered keys. UUID v7 can improve locality for common insertion patterns, but it does not make every database query faster and does not replace proper schema and index choices.

Choose a database's native UUID type when available and suitable. Otherwise, store the 128-bit value consistently as binary or as canonical text. Avoid mixing representations or changing letter case and hyphen rules in ways that complicate comparisons. UUID text is useful for APIs and logs; compact binary storage may be appropriate internally if your database and application handle it consistently.

Formatting and handling UUIDs

For interchange, use the standard five-part form of 8-4-4-4-12 hexadecimal characters. The version appears in the first digit of the third group, so 4 indicates v4 and 7 indicates v7. UUIDs are identifiers, not values to perform arithmetic on; do not remove characters or reformat them unless the receiving system expects that representation.

When validating input, check the expected structure and, if relevant, that the version is one your application accepts. A structurally valid UUID can still refer to no record, and checking its format does not establish ownership or permission. Preserve the full value when copying UUIDs into URLs, JSON, or database queries, and use parameterized queries when inserting them into SQL.

For example, an order service and a shipping service can each create records without coordinating a shared numeric counter. They can use v4 if independent generation and no exposed time are priorities, or v7 if time-oriented index behavior is useful and showing an approximate creation time is acceptable. In both cases, the database should enforce uniqueness, and the services should agree on the same UUID format and storage type.

Summary

• UUIDs are 128-bit identifiers, commonly written as 32 hexadecimal digits with hyphens.
• UUID v4 uses random data; UUID v7 puts a millisecond timestamp first and is designed for time-based sorting.
• Collisions are unlikely with sound generation, not impossible; use a database uniqueness constraint.
• UUIDs can support distributed database keys, but they are not secrets or authorization tokens.