# PostgreSQL 18 UUIDv7 performance analysis reveals high cost of random UUIDv4 keys

> **Key takeaway:** Using random UUIDv4 primary keys in PostgreSQL causes significant performance degradation and increased WAL write volume once indexes exceed available memory.

**Published:** 2026-11-05T12:00:00+00:00 
**Source:** Planet PostgreSQL 
**Category:** databases-storage 
**Canonical URL:** https://fosswire.org/news/postgresql-18-uuidv7-performance-analysis-reveals-high-cost-.html 

## Summary
A technical investigation into PostgreSQL 18 performance highlights the heavy operational costs of using UUIDv4 (random) primary keys compared to UUIDv7 (time-ordered) or integer keys. While performance remains comparable while indexes fit in memory, the gap widens drastically once the index outgrows the shared buffers and page cache.

Testing conducted by DBLab Forge on PostgreSQL 18 shows that at 100 million rows, UUIDv4 inserts achieved only 62% to 69% of the throughput of ordered keys. Furthermore, the random nature of UUIDv4 leads to significantly higher Write-Ahead Log (WAL) overhead, writing 1.5 to 1.9 times more data per row due to frequent index leaf re-imaging during checkpoints.

## Performance degradation and WAL overhead
- **Insert Throughput:** At 100 million rows, UUIDv4 insert rates dropped to 0.62–0.69 of the rate seen with ordered keys because each insert targets a random index leaf, necessitating buffer reads and evicted-page writes.
- **WAL Write Amplification:** UUIDv4 generated 1.5 to 1.9 times more WAL per row than ordered keys at high row counts, as random leaf updates force more frequent full-page images during checkpoint cycles.
- **Memory Pressure:** Random UUIDv4 keys cause the index to crowd out other data from the shared_buffers, whereas UUIDv7 maintains a much smaller working set by appending to the end of the index.
- **Ordering and Locality:** Unlike ordered keys, a 'DESC' sort on a UUIDv4 primary key returns random values rather than the most recent rows, and generating UUIDv7 within the database is recommended to mitigate clock skew issues seen in application-side generation.

## Why it matters
Database administrators and software engineers should favor UUIDv7 over UUIDv4 for primary keys in PostgreSQL 18 to ensure predictable scaling. This transition reduces storage I/O, lowers WAL volume, and prevents performance cliffs as datasets grow beyond available RAM.