For over two decades, the 128-bit Universally Unique Identifier version 4 (UUIDv4)—standardized in 2005 under RFC 4122—served as the default primary key standard across distributed software systems. By relying on 122 bits of cryptographically secure pseudorandom entropy, UUIDv4 eliminated database key coordination, preventing auto-increment ID collision risks across multi-region microservices.
However, as database tables scaled into hundreds of millions of rows, architects encountered an insidious bottleneck: B-Tree index degradation. The uniform randomness of UUIDv4 forces database storage engines (such as PostgreSQL B-Trees, MySQL InnoDB clustered indexes, and MongoDB wiredTiger indexes) to insert records at completely random physical leaf locations. This results in heavy index page splitting, buffer cache thrashing, and high disk I/O.
In 2024, the IETF ratified RFC 9562 ("New UUID Formats"), introducing UUIDv7. UUIDv7 combines a 48-bit Unix epoch millisecond timestamp with 74 bits of entropy, unlocking chronological sorting while retaining global uniqueness. In this technical deep dive, we compare UUIDv4 and UUIDv7 bit architectures, evaluate B-Tree indexing benchmarks, analyze collision mathematics, and demonstrate generation via the Collabsource UUID Generator.
The Database Dilemma: Why UUIDv4 Breaks B-Tree Indexes
Relational databases store primary keys inside balanced tree (B-Tree or B+Tree) indices. In clustered index engines like MySQL InnoDB, the entire data row is physically co-located on disk according to the primary key's sort order.
The Mechanics of Index Page Splitting
When sequential auto-incrementing integers or time-ordered keys are inserted, the database writes sequentially to the rightmost leaf page of the B-Tree. When a page fills to its capacity (typically 8KB or 16KB), the engine cleanly allocates a new page at the end of the index without disturbing existing pages.
Conversely, because UUIDv4 keys are uniformly distributed across the entire 128-bit address space, every incoming row has an equal probability of belonging to any page in the entire database:
- Cache Eviction: Because insertion targets are random, the database engine can no longer keep active index pages warm in RAM (buffer pool). It must constantly page index blocks from SSD to memory.
- 50% Page Splitting: When a random insertion lands on a full page, the engine must split the page in half, move 50% of the rows to a newly allocated page, and update parent tree pointers.
- Storage Bloat: As a consequence of continuous 50/50 page splitting, UUIDv4 indexes typically run at only 50–60% storage density, doubling the memory required to hold the index.
RFC 9562 UUIDv7 Bit Layout & Structure
UUIDv7 solves the indexing problem by prefixing a big-endian timestamp to the identifier:
| Field Name | Bit Length | Purpose & Binary Content |
|---|---|---|
| unix_ts_ms | 48 bits | Big-endian unsigned integer measuring Unix epoch milliseconds (valid until the year 10889 AD). |
| ver | 4 bits | Fixed version identifier: binary 0111 (hexadecimal 0x7). |
| rand_a | 12 bits | Sub-millisecond fraction, monotonic sequence counter, or pseudorandom bits. |
| var | 2 bits | RFC 4122 / 9562 variant flag: binary 10xx. |
| rand_b | 62 bits | Cryptographically secure pseudorandom entropy. |
Generate High-Entropy UUIDv4 and UUIDv7 Identifiers
Generate single or bulk cryptographically secure RFC 9562 UUIDs directly inside your browser.
Launch UUID Generator →128-Bit Entropy & Collision Probability Mathematics
A frequent concern when adopting time-ordered keys is whether shortening the random entropy from 122 bits (v4) to 74 bits (v7) elevates the risk of duplicate key generation in distributed microservices.
Under the mathematical principle of the Birthday Problem, the probability \(p\) of at least one collision occurring when generating \(n\) identifiers across an entropy pool of \(N = 2^{74}\) possibilities is approximated by:
\(p(n) \approx 1 - e^{-\frac{n^2}{2N}} \approx \frac{n^2}{2 \cdot 2^{74}} = \frac{n^2}{2^{75}}\)
Because the 74-bit entropy resets every single millisecond:
- To reach a 1 in a billion (0.0000001%) chance of collision, a distributed cluster would need to generate 8.6 million UUIDv7s within the exact same millisecond (8.6 billion IDs per second).
- Generating 100,000 IDs per millisecond (100 million requests/sec) yields a collision probability of only \(2.6 \times 10^{-13}\).
Client-Side JavaScript Implementation (RFC 9562)
While modern browsers natively support crypto.randomUUID() for UUIDv4, UUIDv7 can be computed in lightweight client-side JavaScript using the Web Crypto API:
// Pure client-side RFC 9562 UUIDv7 generator
function generateUUIDv7() {
const bytes = new Uint8Array(16);
crypto.getRandomValues(bytes);
// 1. Fill 48-bit Unix timestamp (milliseconds)
const now = Date.now();
bytes[0] = (now / 0x10000000000) & 0xff;
bytes[1] = (now / 0x100000000) & 0xff;
bytes[2] = (now / 0x1000000) & 0xff;
bytes[3] = (now / 0x10000) & 0xff;
bytes[4] = (now / 0x100) & 0xff;
bytes[5] = now & 0xff;
// 2. Set Version 7 (0111xxxx)
bytes[6] = (bytes[6] & 0x0f) | 0x70;
// 3. Set Variant 1 (10xxxxxx)
bytes[8] = (bytes[8] & 0x3f) | 0x80;
// 4. Format into canonical 8-4-4-4-12 hex string
const hex = Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join('');
return `${hex.slice(0, 8)}-${hex.slice(8, 12)}-${hex.slice(12, 16)}-${hex.slice(16, 20)}-${hex.slice(20)}`;
}Frequently Asked Questions
Summary & Architecture Recommendations
For high-throughput distributed applications, UUIDv7 represents the ideal balance between autonomous decentralized key creation and high-efficiency database index caching. Transitioning new table schemas from UUIDv4 to UUIDv7 eliminates B-Tree page splits and ensures long-term database scalability.