GUID / UUID v6 - Reordered Time-Based Identifier
RFC 9562 - ietf.org
GUID / UUID v6 is a time-based UUID designed to be sortable by creation time using simple string/byte comparisons. It is essentially GUID / UUID v1 with the timestamp bytes reordered so that the most significant time bits come first.
Practically, this makes v6 attractive for databases and storage engines that suffer when keys are inserted in random order. If you already use v1 (or must remain compatible with v1-style fields), v6 provides the same information while behaving better in indexes.
Like v1, v6 can include a node identifier (often a MAC address) and a clock sequence. Many implementations replace the node identifier with a random 48-bit value for privacy, but behavior can vary by implementation.
Advantages
- Lexicographically sortable by time: values generated later generally sort after earlier ones without parsing fields.
- Better database locality: reduced index fragmentation compared to fully random GUIDs / UUIDs in many common B-tree style indexes.
- Field-compatible with v1: keeps the familiar concepts of timestamp, clock sequence, and node identifier while improving ordering.
- No central coordination required: can be generated independently across machines and services.
- Good for distributed IDs with ordering: helps when you want IDs that roughly reflect creation order (logs, events, records).
- Easy validation: version nibble and variant bits provide quick sanity checks during parsing.
- Works in the standard GUID / UUID string format: stays compatible with the canonical
8-4-4-4-12 representation and common tooling.
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.
Canonical format: 8-4-4-4-12
Example (v6): 1ec9414c-232a-6b00-b3c8-9c9b5f0a2b1d
Version nibble: xxxxxxxx-xxxx-6xxx-xxxx-xxxxxxxxxxxx
^ first hex of the 3rd group is "6" for v6
Variant nibble: xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx
^ N is typically 8, 9, a or b (RFC variant)
Tip: when you split a UUID into 8-4-4-4-12, the first hex character of group 3 is the version. If it's 6, it's GUID / UUID v6.
Practical bit layout (high level): GUID / UUID v6 starts with the higher timestamp bits first (time_high then time_mid), inserts the version nibble, then stores the remaining lower timestamp bits (time_low). The clock sequence and node fields follow in the same relative positions as v1.
Conclusions
Use UUID v6 when you want a UUID that is time-based like v1 but also sorts naturally in databases and logs. If you're designing a new system without v1 compatibility needs, consider UUID v7 instead. And if you do use v6, prefer implementations that avoid exposing MAC addresses unless you explicitly need them.