UUID v1 vs. v4 vs. v7: A Practical RFC 9562 Guide

A UUID is always 128 bits, or 16 octets. Its standard string representation groups hexadecimal digits as 8-4-4-4-12, for example 550e8400-e29b-41d4-a716-446655440000.

• Version: four bits at bit positions 48–51, represented by the 13th hexadecimal digit in the standard string. Values 1 through 8 identify the version.
• Variant: a variable-length field beginning at bit 64. The variant primarily used by RFC 9562 begins with 10, so the 17th hexadecimal digit is 8 through b.
• The other 122 bits: interpreted according to the version when using that RFC variant.

For a versioned UUID, the 13th hexadecimal digit reveals the version: the underlined 4 in 550e8400-e29b-41d4-... marks v4. NIL and Max UUIDs are special forms rather than ordinary versioned UUIDs.

UUID v1 combines a 60-bit timestamp measured in 100-nanosecond intervals since October 15, 1582 with a 48-bit node identifier, historically often a MAC address.

time-low : 32 bits   ← low-order timestamp bits
time-mid : 16 bits
time-high: 12 bits + version (4 bits)
clock-seq: 14 bits + variant (2 bits)
node     : 48 bits   ← MAC address or random value

Advantage: the timestamp can be recovered, and the design combines it with a clock sequence and node identifier to maintain uniqueness. The timestamp fields are not arranged from most to least significant, however. Sorting the standard string or 128-bit value does not preserve creation order over long periods. UUID v6 rearranges these fields to improve that property.

Risk: an implementation that uses a real MAC address as the node identifier can reveal information about the generating node. RFC 9562 also allows a random or pseudorandom node ID, so check the behavior of the library you deploy.

For UUID v4 using the RFC 9562 variant, the 122 bits outside the version and variant fields are generated as uncorrelated random or pseudorandom values. This makes v4 one of the simplest general-purpose choices.

Collision probability: the 122-bit space contains about 5.3 × 10³⁶ values. Assuming independent uniform generation, the birthday-bound approximation for one billion UUIDs is about 9.4 × 10⁻²⁰. Real reliability still depends on a sound random-number generator and a conforming implementation.

Advantage: the value itself embeds neither a generation timestamp nor a node identifier.

Trade-off: v4 has no time ordering, so insert positions are distributed across a B-tree. Effects on page splits and cache behavior vary with the database, index design, and workload.

UUID v7 begins with a Unix timestamp and is designed to sort by time. Compared with random v4 values, it can provide better locality in B-trees and similar structures, although the measured benefit depends on the database, index, and write pattern.

unix_ts_ms: 48 bits   ← Unix timestamp in milliseconds
version   : 4 bits    (= 7)
rand_a    : 12 bits   ← random or monotonicity field
variant   : 2 bits    (= 10)
rand_b    : 62 bits   ← random or monotonicity field

Because the most significant 48 bits contain the timestamp, UUIDs with different embedded millisecond values sort chronologically when compared as unsigned 128-bit values or in RFC byte order. The standard text form preserves that order only when hexadecimal letter case is normalized and the collation follows code-point order. A database-native UUID type avoids text collation, but verify the product's documented comparison order; compare bytes in RFC order when that ordering is required. Ordering within the same millisecond is not automatic. It requires an implementation that uses a sub-millisecond fraction, a counter, or another monotonic construction.

• New values tend to cluster in nearby B-tree regions instead of scattering like random v4 values.
• Applications can compare UUIDs or extract their generator-supplied timestamps for approximate ordering and coarse range filtering. The embedded timestamp is not authoritative event or audit time, so keep a separate created_at or event-time field when exact business timing matters.
• The remaining 74 bits can all be random, or part of them can encode a sub-millisecond value or counter.

RFC 9562 recommends v7 over v1 or v6 when possible. It does not say that v7 must replace v4 in every application. Choose v7 when an embedded timestamp and time locality are useful; choose v4 when you do not want the identifier to reveal generation time. PostgreSQL 18, which has been released, provides uuidv7() and uuid_extract_timestamp() as built-in functions.

UUID v6 rearranges the 60-bit v1 timestamp from most to least significant. It supports systems that need to transform existing v1 values or retain timestamp, clock-sequence, and node semantics while gaining sortable fields. Using a MAC address for the node retains the privacy concern found in v1. RFC 9562 recommends v7 over v1 or v6 when possible.

UUID v8 reserves 122 bits for experimental or vendor-specific layouts. RFC 9562 does not provide uniqueness or collision-resistance guarantees for the custom fields. Use it only when the application can define and maintain the bit layout, collision properties, and information-disclosure rules as its own specification.

RFC 9562 defines two special UUID values:

• NIL UUID: all bits zero, 00000000-0000-0000-0000-000000000000.
• Max UUID: all bits one, ffffffff-ffff-ffff-ffff-ffffffffffff.

They are explicitly defined special forms, not ordinary versioned UUIDs. An application can use NIL as an unset sentinel or Max as an upper comparison bound, but those meanings belong to the application's own contract.

1. Text versus a native or 16-byte representation: a hyphenated ASCII UUID has 36 characters, while the UUID itself is 16 bytes. Actual storage and index costs depend on the database type, collation, and page structure. Standardize conversions when using PostgreSQL's uuid type or a binary representation in MySQL.
2. Same-millisecond ordering: if all 74 non-timestamp bits are independently random, values created within one millisecond do not sort by generation order. If that order matters, verify which RFC 9562 monotonic method the library implements and how it handles clock rollback and concurrent generation.
3. Randomness for v4: Math.random() is not cryptographically secure. Use crypto.randomUUID() in browsers and Node.js, or uuid.uuid4() in Python.

• RFC 9562 is the current UUID specification and obsoletes RFC 4122.
• The 13th hexadecimal digit identifies the version of a versioned UUID.
• v1 embeds time and a node ID but does not sort chronologically in its standard field order.
• v4 provides 122 random bits and does not embed creation time.
• v7 combines a 48-bit Unix-millisecond timestamp with 74 other bits and is a strong candidate when time locality matters.
• v8's custom layout does not inherit automatic uniqueness or security guarantees.
• Use a cryptographic random source and a storage representation appropriate to the database.