UUID v4 vs UUID v7: Why Random UUIDs Kill Database B-Tree Performance
Learn why random UUID v4 causes catastrophic B-Tree page splits and cache churn in PostgreSQL and MySQL, and how time-ordered UUID v7 solves it.
UUID v4 is completely random, causing inserts into database primary key B-Tree indexes to land arbitrarily across memory pages. As tables exceed RAM, this triggers constant page splits and disk I/O churn. UUID v7 (RFC 9562) embeds a 48-bit millisecond timestamp prefix, making inserts strictly sequential while retaining global uniqueness.
Solve this problem now with our free UUID / GUID Generator
Try it instantly in your browser — zero tracking, 100% client-side privacy.
Specification & Architecture Reference
| Metric / Feature | UUID v4 (RFC 4122) | UUID v7 (RFC 9562) |
|---|---|---|
| Generation Source | 122 bits of pseudo-random entropy | 48-bit timestamp + 74 bits of entropy |
| Sort Order | Unordered (Completely random) | Chronologically ordered by creation time |
| B-Tree Insert Performance | Degrades sharply once index > RAM | Append-only efficiency (matches auto-increment BIGINT) |
| Page Split Frequency | Extremely High (Random insertions) | Near Zero (Always inserts on rightmost leaf) |
| Data Leakage Risk | Zero time or location leakage | Exposes millisecond creation time (not MAC) |
Why UUID v4 Slows Down at Scale
When a database table uses standard **UUID v4** as a primary key, insertions perform well while the dataset is small. However, as the table grows to millions of rows and the B-Tree index no longer fits entirely within the buffer cache (PostgreSQL `shared_buffers` or MySQL InnoDB buffer pool), write throughput often degrades significantly.
The Mechanics of B-Tree Page Splits A B-Tree index organizes keys in sorted order across 8KB or 16KB disk pages. - With auto-incrementing integers, each new row is inserted into the **rightmost leaf page**, requiring minimal page rebalancing. - With random UUID v4, every insert targets a random page across the entire tree. - When an insertion targets a page that is already 100% full, the database engine must execute a **page split**: it pauses the write, allocates a new page, moves 50% of the rows over, and writes both pages back to disk.
This results in heavy **disk I/O amplification** and leaves B-tree leaf pages only ~50-70% full, effectively doubling your disk footprint.
How UUID v7 Solves the Problem Standardized in **RFC 9562 (2024)**, UUID v7 replaces the first 48 bits of the UUID with a Unix millisecond timestamp:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Because timestamps increase monotonically, new rows naturally append to the right edge of the B-Tree, achieving the write speed of auto-incrementing integers alongside the distributed benefits of UUIDs.
Generate compliant UUID v4 and UUID v7 keys in bulk with Mickytool's **UUID / GUID Generator**.
Solve this problem now with our free UUID / GUID Generator
Execute this workflow immediately without saving data on remote servers.
Frequently Asked Questions
Can an attacker deduce when a UUID v7 was created?
Yes. The first 48 bits encode the exact millisecond timestamp. If record creation time must remain secret, use UUID v4 instead.
Is UUID v7 supported natively in PostgreSQL 17?
PostgreSQL 17 includes uuid_generate_v7() through pg_uuidv7 extensions, and native core support is being integrated across modern database releases.