Why UUIDv4 Slows Your Database Writes and How Switching to UUIDv7 Boosts Performance

Engineers reach for UUIDv4 because it guarantees global uniqueness without any coordination. A 128‑bit random value lets every microservice generate IDs independently, hides business metrics, and prevents enumeration attacks. The trade‑off, however, is hidden deep inside the storage engine.

Relational databases store primary keys in B‑Tree indexes. When keys are sequential, inserts simply append to the rightmost leaf page, keeping pages full and I/O predictable. Random UUIDv4 keys break that locality:

• 340% latency spike after crossing 50 million rows, even though CPU and query plans look normal.
• I/O saturation caused by constant page‑fetches from disk—each random insert forces a cold 8 KB/16 KB page read.
• Index bloat – page splits leave leaves at only ~60 % fill factor, inflating the primary‑key index to 39 MB versus 21 MB for an ordered key.

These effects cascade: more disk writes, higher WAL volume (412 MB vs 158 MB), and slower write throughput (14.8 s vs 4.9 s for 1 M rows). When the index outgrows RAM, the performance gap widens to 5‑10× because every insert waits on physical I/O.

Switching to a time‑ordered UUID (UUIDv7) preserves the distributed benefits while restoring B‑Tree locality. Because the first 48 bits encode a monotonically increasing timestamp, inserts behave like sequential integers:

• 46% smaller index and 37% less wasted space (fill factor jumps from 59 % to 97 %).
• 3× faster writes at 1 M rows, and dramatically lower WAL pressure.
• No schema changes needed—UUIDv7 shares the same 16‑byte binary layout as UUIDv4.

**Strategic benefit:** Keep the safety of globally unique IDs, eliminate costly page splits, and regain the write performance you expect from auto‑increment keys. The hidden cost of random UUIDv4 is real; the solution is a simple generator swap and native 16‑byte storage.

When you choose a UUIDv4 primary key you are trading coordination simplicity for a hidden I/O monster. Each 128‑bit value lands at a random spot inside the B‑Tree index, forcing the engine to hunt for a cold leaf page on every INSERT.

In PostgreSQL a leaf page is a fixed 8 KB block; in MySQL InnoDB it is 16 KB. With sequential keys the database simply appends to the right‑most page, keeping the buffer pool hot and the write path short. Random UUIDv4 keys, however, trigger three costly actions:

• Cache miss on every write: the target leaf page is rarely in memory, so the engine reads a full 8 KB/16 KB page from disk before it can add a 16‑byte key.
• Frequent page splits: most middle pages are already full, so the system splits them in half, moves ~50 % of the entries, and updates parent pointers.
• WAL amplification: each split writes a full‑page image to the Write‑Ahead Log, inflating disk writes by more than three‑fold.

These mechanics shrink the average leaf density to about 59 % for UUIDv4, while a time‑ordered identifier (UUIDv7) achieves nearly 97 % fill factor. The result is a bloated index (39 MB vs 21 MB for 1 M rows) and a WAL volume of 412 MB versus 158 MB – a 61 % increase in write amplification.

When the index outgrows the buffer pool, the random reads become physical I/O, and write latency can spike by 300 % or more, as real‑world benchmarks have shown.

Strategic benefits of fixing the problem:

• Half the index size: less RAM and storage consumption.
• Up to 3× faster inserts: fewer cache misses and no page‑split overhead.
• Reduced WAL traffic: lower backup windows and cheaper replication.
• Predictable performance at scale: your system stays fast even past 100 M rows.

Switching to a monotonic UUID (e.g., UUIDv7) preserves global uniqueness while letting the B‑Tree behave like a sequential key. The change is a drop‑in replacement in code and requires no schema rewrite, yet it restores the I/O locality that modern databases rely on for high‑throughput workloads.

When you scale a write‑heavy PostgreSQL table, the choice of primary key can be the difference between a smooth ride and a costly bottleneck. The reproducible benchmark below shows exactly how a random UUIDv4 drags performance down, while the time‑ordered UUIDv7 restores the speed you expect from sequential keys.

In a controlled test inserting 1 000 000 rows, the two UUID versions produced starkly different results:

• Insert time: UUIDv4 took 14.8 seconds versus 4.9 seconds for UUIDv7 – more than three times faster.
• Primary‑key index size: UUIDv4 grew to 39 MB, while UUIDv7 stayed at 21 MB, a 46 % reduction.
• Leaf density (fill factor): UUIDv4 achieved only 59 % average density, leaving many pages half‑empty; UUIDv7 reached 96 %, keeping pages tightly packed.
• WAL generated: UUIDv4 produced 412 MB** of write‑ahead log**, whereas UUIDv7 generated just 158 MB, cutting log amplification by 61 %.

If you’re still wrestling with the write‑latency spikes and ballooning indexes that come from random UUIDv4 primary keys, it’s time to switch to the time‑ordered UUIDv7. The change is painless because UUIDv7 shares the exact same 128‑bit layout, but it behaves like a sequential key inside your B‑Tree, slashing page splits and WAL churn.

High‑write services often hit a wall when their primary keys are truly random. As the DEV Community post shows, inserting UUIDv4 into a B‑Tree forces the database to chase cold pages, split indexes, and generate excess WAL traffic. The result is a steep rise in IOPS, bloated storage, and latency spikes that erode your bottom line.