What Is UUID v6?
UUID Version 6 is a reordered timestamp UUID defined in RFC 9562. It takes the same timestamp data as UUID v1 — a 60-bit count of 100-nanosecond intervals since October 15, 1582 — but reorganizes the fields so that the most significant bits of the timestamp appear first in the string representation. This single change makes UUID v6 lexicographically sortable while maintaining full backward compatibility with UUID v1.
A UUID v6 looks like: 1ec9414c-232a-6b00-b3c8-9f6bdeced846. The 6 in the third group identifies the version. Unlike v1, the timestamp bits are ordered from most significant to least significant, so string sorting produces chronological order.
UUID v6 vs. UUID v1: The Key Difference
UUID v1 stores the timestamp in a scrambled order: low bits first, then mid, then high. This was a design decision in the original RFC 4122 specification that made v1 UUIDs non-sortable by string comparison. UUID v6 fixes this by reordering the fields: high bits first, then mid, then low.
The practical result: if you sort a list of UUID v6 values alphabetically, you get them in chronological order. This is a critical property for database indexes, where sequential inserts dramatically outperform random inserts.
Beyond the field reordering, UUID v6 is structurally identical to v1. The same timestamp epoch (October 15, 1582), the same 100-nanosecond resolution, the same clock sequence, and the same node ID field. Any system that can parse UUID v1 can parse UUID v6 with a minor version check.
The Internal Structure of UUID v6
The 128 bits of UUID v6 are organized as:
- →time_high (32 bits): The high 32 bits of the 60-bit timestamp. Appears first — this is what makes v6 sortable.
- →time_mid (16 bits): The middle 16 bits of the timestamp.
- →time_low_and_version (16 bits): The low 12 bits of the timestamp plus the 4-bit version field (set to
0110). - →clock_seq (14 bits): Same clock sequence as v1 — increments on clock regression.
- →node (48 bits): Node identifier — our generator uses a cryptographically random value for privacy.
RFC 9562: The Standard That Introduced UUID v6
UUID v6 was introduced in RFC 9562, ratified by the IETF in May 2024. This RFC supersedes RFC 4122 and adds three new UUID versions: v6 (reordered time), v7 (Unix epoch time), and v8 (custom/experimental). RFC 9562 was motivated by the widespread need for time-ordered UUIDs that work well as database primary keys.
UUID v6 was specifically designed as a drop-in replacement for v1 in systems that already use v1 but want sortability. If you are starting a new system, RFC 9562 recommends UUID v7 over v6, as v7 uses the simpler Unix epoch timestamp and has no dependency on the Gregorian epoch.
When to Use UUID v6
UUID v6 is the right choice when:
- →Migrating from UUID v1: You have an existing system using v1 and want sortability without changing the timestamp epoch or resolution. UUID v6 is a minimal change.
- →v1 library compatibility: Your UUID library supports v1 and v6 but not v7. UUID v6 gives you sortability with existing tooling.
- →100-nanosecond precision: You need sub-millisecond timestamp precision in your IDs. UUID v6 inherits v1's 100ns resolution, while v7 only has millisecond precision.
- →Gregorian epoch compatibility: Your system needs to interoperate with other systems that use the Gregorian epoch (October 15, 1582) for timestamp calculations.
UUID v6 vs. UUID v7: Which Should You Choose?
For new systems, RFC 9562 recommends UUID v7. It uses the Unix millisecond timestamp (simpler, more familiar), has 74 bits of randomness (vs. v6's 62 bits), and is already widely supported in modern UUID libraries.
For systems migrating from UUID v1, UUID v6 is the natural upgrade path. The structural similarity means migration is straightforward, and any code that handles v1 can handle v6 with minimal changes.
Both v6 and v7 solve the core problem of UUID v4 as a database primary key: random insertion causing B-tree index fragmentation. Either version will dramatically improve INSERT performance on large tables compared to v4.
Database Performance with UUID v6
The sortability of UUID v6 directly translates to better database performance. In a B-tree index (used by PostgreSQL, MySQL, SQL Server, and most other relational databases), sequential inserts are far more efficient than random inserts:
- →UUID v4 (random): Each new record is inserted at a random position in the index, causing frequent page splits and high write amplification.
- →UUID v6 (sortable): New records are always appended near the end of the index. Pages fill sequentially, splits are rare, and write amplification is minimal.
Benchmarks on PostgreSQL with 100 million rows show UUID v6/v7 achieving 2–5x better INSERT throughput compared to UUID v4, with significantly lower index bloat.
Converting Between UUID v1 and v6
Because v6 is a field reordering of v1, conversion between the two is lossless and deterministic. Any UUID v1 can be converted to its v6 equivalent and back. This makes migration from v1 to v6 safe — you can convert existing IDs without losing any information.
Most modern UUID libraries (Python's uuid6, JavaScript's uuidv7, Go's github.com/google/uuid) support both v1 and v6 with built-in conversion functions.
