Understanding UUID Version 7: The Modern RFC 9562 Standard
For more than two decades, UUID Version 4 (RFC 4122) served as the industry standard for distributed systems. However, as high-scale transactional databases expanded, developers encountered a critical systemic flaw: pure random identifiers destroy database B-Tree index performance.
In May 2024, the Internet Engineering Task Force (IETF) officially published RFC 9562, introducing UUID Version 7 (UUIDv7) to solve this fundamental database bottleneck while preserving all security, privacy, and decentralized benefits of 128-bit UUIDs.
The "Random UUID Tax": Why B-Tree Indexes Degrade Under UUID v4
In relational database engines such as PostgreSQL, MySQL (InnoDB), and SQLite, tables with primary keys are organized physically as Clustered B-Tree Indexes. When records are inserted sequentially:
- Auto-incrementing integers (BIGINT): New records always append to the rightmost leaf page of the B-Tree index. The database keeps this single leaf page in high-speed RAM buffer cache, resulting in O(1) append efficiency and minimal disk I/O.
- Random UUID v4: Because the first bytes are entirely random, each insertion targets a completely unpredictable leaf page across the tree. Once your database table index exceeds available RAM (PostgreSQL
shared_buffersor MySQLinnodb_buffer_pool_size), each insert triggers a random disk read, cache eviction, and frequent B-Tree 50% page splits.
This index degradation, known as the Random UUID Tax, causes write throughput to drop by up to 80% as tables grow beyond millions of rows. UUID Version 7 eliminates this bottleneck entirely.
RFC 9562 Bit Layout: How UUID v7 Combines Time and Entropy
UUID Version 7 replaces the legacy Gregorian timestamp format of UUID v1 with standard Unix Epoch time in milliseconds, followed by cryptographically secure pseudo-random entropy.
| Field Name | Bit Range | Bit Width | Description & Purpose |
|---|---|---|---|
unix_ts_ms |
0 – 47 | 48 bits | Big-Endian Unix Epoch timestamp in milliseconds. Valid until year 10,889 AD without overflow. |
ver |
48 – 51 | 4 bits | Binary 0111 (7), indicating UUID Version 7 under RFC 9562. |
rand_a |
52 – 63 | 12 bits | Sub-millisecond counter or cryptographic entropy to ensure sorting precision. |
var |
64 – 65 | 2 bits | Binary 10, indicating standard Variant 1 (RFC 4122 / RFC 9562). |
rand_b |
66 – 127 | 62 bits | Cryptographically secure random bytes generated via CSPRNG (Web Crypto / /dev/urandom). |
Comparative Benchmark: UUID v4 vs UUID v7 vs ULID vs BIGINT
The table below summarizes the architectural trade-offs between legacy random UUIDs, time-ordered UUIDv7, ULID, and auto-increment integers:
| Identifier Type | Standard Status | B-Tree Locality | Distributed Safe | Storage Size | Sortable By Default |
|---|---|---|---|---|---|
| UUID v7 | IETF RFC 9562 (Official) | Excellent (Append-mostly) | Yes (Decentralized) | 128 bits (16 bytes) | Yes (Chronological) |
| UUID v4 | IETF RFC 4122 (Legacy) | Terrible (Random splits) | Yes (Decentralized) | 128 bits (16 bytes) | No (Random) |
| ULID | Community Spec | Excellent (Append-mostly) | Yes (Decentralized) | 128 bits (Crockford Base32) | Yes (Lexicographical) |
| BIGINT | Database Native | Optimal | No (Coordination bottleneck) | 64 bits (8 bytes) | Yes (Sequential) |
Extracting Creation Timestamps from UUID v7
Because the first 48 bits of a UUID v7 encode milliseconds since the Unix Epoch, you can extract the exact creation timestamp directly from the identifier string without performing a secondary database column lookup:
// JavaScript / TypeScript: Extract Date from UUID v7
function extractTimestamp(uuid) {
const hexTime = uuid.replace(/-/g, '').substring(0, 12);
const epochMs = parseInt(hexTime, 16);
return new Date(epochMs);
}
// Example:
const created = extractTimestamp('018e6e5a-8b20-7b2c-80a5-f129528e18f9');
console.log(created.toISOString()); // e.g. 2024-03-24T14:22:15.136ZFrequently Asked Questions About UUID v7
UUID Version 7 is a standardized 128-bit identifier published by the IETF in RFC 9562 in May 2024. It was specifically engineered to replace random UUIDv4 in database systems, combining a 48-bit millisecond Unix Epoch timestamp with 74 bits of cryptographic entropy to ensure optimal B-Tree index insertion performance without centralized coordination.
Because the first 48 bits encode a continuously increasing Unix timestamp, every new UUID v7 is numerically greater than previously generated IDs. In relational databases (PostgreSQL, MySQL, SQLite), new records are appended sequentially to the rightmost leaf of the B-Tree index, completely avoiding the random 50% page splits caused by UUID v4.
Yes. The first 48 bits explicitly reveal the millisecond when the UUID was minted. If your application requirements treat creation timestamps as confidential business secrets (e.g., hiding exact order volume velocity from competitors), use pure random UUID v4 or an encrypted identifier.
Yes, 100%. Both UUID v4 and UUID v7 conform to the standard 128-bit length and canonical 8-4-4-4-12 hyphenated string formatting. Existing database column types (such as PostgreSQL uuid, SQL Server uniqueidentifier, and MySQL BINARY(16)) accept UUID v7 without requiring any schema changes.
With 74 bits of cryptographic randomness per millisecond, generating a collision within the same millisecond requires over 100 million simultaneous operations on a single node (50% collision probability at 2^37 operations). Across distributed clusters, collisions are mathematically negligible.