GUID / UUID V6 - Reordered Time-Based Identifier (Sortable)

Version status and history

GUID / UUID v6 was proposed around 2021 as part of the GUID / UUID modernization efforts and standardized in RFC 9562 in May 2024.

V6 is fully supported in RFC 9562 and has no deprecation concerns. It addresses the sortability issues of v1 while maintaining field-level compatibility.

For new systems requiring time-based sortability, RFC 9562 recommends v7 (Unix timestamp-based) over v6, unless v1 compatibility or Gregorian timestamp semantics are required.

Advantages of GUID / UUID v6

• Lexicographically sortable by time: values generated later generally sort after earlier ones without parsing fields, enabling efficient time-based queries.
• Better database locality: reduced index fragmentation compared to fully random GUIDs / UUIDs in many common B-tree style indexes, improving write performance.
• Field-compatible with v1: keeps the familiar concepts of Gregorian timestamp, clock sequence and node identifier while improving ordering.
• No central coordination required: can be generated independently across machines and services without a central authority.
• Good for distributed IDs with ordering: helps when you want IDs that roughly reflect creation order (logs, events, audit records).
• Privacy-safe option: modern implementations use random node IDs instead of MAC addresses, avoiding hardware tracking concerns.
• Easy validation: version nibble and variant bits provide quick sanity checks during parsing.

Warnings

• Privacy risk if MAC-based node IDs are used: v6 can embed a hardware identifier (like v1). Prefer a random node ID if you don't want host tracking.
• Not “secret” or unguessable: time-ordered IDs can leak creation timing patterns and may be more predictable than purely random IDs.
• Ordering is “generally” time-based, not absolute: clock skew, clock adjustments or multi-node generation can still produce out-of-order values.
• Implementation differences: how the clock sequence and node fields are initialized (random vs legacy behavior) can vary by implementation.
• Collision handling depends on generator quality: a bad clock strategy, repeated state, VM cloning or a reused node/sequence combination can increase collision risk in flawed implementations.
• Prefer v7 for new systems: RFC 9562 recommends GUID / UUID v7 for systems that don't need legacy v1 semantics, since v7 uses a Unix-time-based design and is commonly favored for modern DB keys.

Technical description

What fields exist: GUID / UUID v6 reuses the same building blocks as GUID / UUID v1: a 60-bit timestamp (Gregorian epoch, 100-nanosecond units), a clock sequence (used to help uniqueness when time doesn't strictly increase) and a 48-bit node identifier (traditionally a MAC address, but often randomized for privacy).

Ordering behavior: v6 is designed so the timestamp bytes appear from most significant to least significant early in the GUID / UUID. That means a straightforward lexical sort of the canonical string usually groups values in creation-time order (unlike v1, where time bits are split in a way that breaks simple sorting).

Version and variant in practice: the GUID / UUID version is encoded in the first hex digit of the third group (it will be 6 for v6). The most common layout variant used on the web and in RFC 9562 is the “DCE” variant, where the variant bits are 10xx in the relevant byte.

Try our GUID / UUID Inspector to see the structure of v6 GUIDs / UUIDs.

Format and structure

GUID / UUID v6 uses the standard 8-4-4-4-12 canonical format with 32 hexadecimal digits separated by hyphens (36 characters total).

Canonical format:  8-4-4-4-12
Example (v6):      1ec9414c-232a-6b00-b3c8-9c9b5f0a2b1d
Layout:            xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
                                 ^    ^
                                 |    └─ N = Variant: is typically 8, 9, a or b (RFC variant)
                                 └────── M = Version: first hex digit of the 3rd group is "6" for v6
                

Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v6 it is 6. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex). The timestamp bytes are ordered for lexicographical sorting.

Frequently Asked Questions

Conclusion

GUID / UUID v6 is ideal when you need a time-sortable UUID with v1field compatibility. It addresses v1's sortability issues while maintaining the same timestamp, clock sequence and node structure. For new systems without v1 compatibility requirements, RFC 9562 recommends v7, which offers simpler Unix timestamp-based design. If you use v6, prefer implementations that use random node IDs to avoid MAC address privacy concerns.