UUID v4 vs. UUID v7: The Evolution of Universally Unique Identifiers in Modern Databases

Why Sequential Auto-Increment IDs Fail at Scale#

Sequential integers (`BIGINT`) introduce severe architectural bottlenecks:

• Centralized Bottleneck: Only the primary database master can allocate the next ID, preventing offline creation.
• Enumeration Vulnerabilities: Predictable IDs allow malicious scrapers to crawl `/user/1`, `/user/2`, etc.
• Sharding Complexity: Merging tables from multiple database shards results in primary key collisions.

UUID v4: Pure Randomness and Collision Probabilities#

UUID v4 solved the decentralization problem by generating 122 bits of cryptographically secure pseudo-random entropy (e.g. `c7b8d4e0-3e28-4e1b-9f4a-8d1e2f3a4b5c`).

To generate a single collision with UUID v4, you would need to generate **1 billion UUIDs per second for approximately 85 years**.

The Hidden Cost of UUID v4: B-Tree Index Fragmentation#

Because UUID v4 is completely random, inserting new rows into a clustered B-Tree index (like PostgreSQL, MySQL InnoDB, or SQLite) requires inserting keys into random physical memory pages.

As tables grow beyond available RAM, this causes constant disk thrashing, page splits, and degraded write throughput.

UUID v7 (RFC 9562): Time-Ordered Sortable Entropy#

UUID v7 embeds a 48-bit Unix timestamp (millisecond precision) into the most significant bits, followed by 74 bits of cryptographically secure random entropy:

 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                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Database Benchmark: Insert Performance Comparison#

Because UUID v7 values are monotonically increasing over time, new database inserts are always appended to the rightmost leaf of the B-Tree index.

Database benchmarks in PostgreSQL demonstrate that **UUID v7 achieves up to 4x faster insert throughput** compared to UUID v4 on tables with over 50 million records.