Understanding UUID v4 vs v7: Generation, Differences, and Database Indexing

What Is a UUID?

A Universally Unique Identifier (UUID), standardized by RFC 4122 and recently modernized by RFC 9562, is a 128-bit value formatted as 32 hexadecimal digits separated by hyphens in an 8-4-4-4-12 pattern:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M represents the UUID version (e.g., 4 for random, 7 for Unix epoch time-sorted).
• N represents the variant (typically 8, 9, a, or b, encoding the 10xx binary variant).

The Hidden Penalty of UUID v4 in Databases

For over two decades, UUID v4 has been the default choice for distributed systems because it requires no central coordination:

f47ac10b-58cc-4372-a567-0e02b2c3d479 (v4: 122 random bits)

However, when used as a primary key in relational databases (such as PostgreSQL, MySQL InnoDB, or SQL Server), UUID v4 causes severe performance degradation as tables scale beyond millions of rows:

1. B-Tree Index Fragmentation: B-Tree indexes require sorted keys. Because UUID v4 values are completely random, new inserts land in arbitrary locations throughout the index tree.
2. Page Splits & Write Amplification: When an index page fills up, the database engine is forced to split the page into two, rewriting existing data to disk.
3. Buffer Pool Cache Eviction: Because incoming writes touch random pages across the entire index, the database cannot keep the “hot” working set in memory, leading to heavy random SSD I/O.

Enter UUID v7: Time-Sorted Distributed Identifiers

Published in RFC 9562, UUID v7 directly eliminates index fragmentation while preserving decentralized generation:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UUID v7 Bit Anatomy:

• Bits 0–47 (48 bits): Big-endian unsigned 48-bit integer recording the Unix timestamp in milliseconds.
• Bits 48–51 (4 bits): Version nibble set to 0111 (0x7).
• Bits 52–63 (12 bits): Sub-millisecond sequence or pseudo-random bits (rand_a).
• Bits 64–65 (2 bits): RFC variant bits set to 10.
• Bits 66–127 (62 bits): Cryptographically secure random entropy (rand_b).

Because the leading 48 bits track real-world time, UUID v7 values sort sequentially by creation time. In B-Tree indexes, new inserts append directly to the rightmost leaf page, reducing page splits to nearly zero.

Feature & Performance Comparison

How to Generate UUIDs Client-Side in Your Browser

In modern browsers, generating cryptographically secure identifiers relies on the Web Cryptography API (crypto.getRandomValues):

// Native Web Crypto UUID v4
const uuidV4 = crypto.randomUUID();
console.log(uuidV4); // e.g. 3b241101-e2bb-4255-8caf-4136c566a962

For UUID v7, client-side tools pack the current Date.now() timestamp into the top 48 bits, set the 0x7 version bits, and populate the remaining 74 bits with cryptographically secure random bytes from crypto.getRandomValues(new Uint8Array(10)).

Try generating batch UUIDs with our Toolbox UUID & GUID Generator.