Random UUIDv4 Primary Keys Can Silently Degrade Database Write Performance

A backend engineer reported a 340% spike in database write latency after their table passed 50 million rows, with CPU usage normal and storage I/O saturated. The cause was using random UUIDv4 values as primary keys, which were chosen to avoid enumeration attacks and simplify distributed ID generation. Relational databases store primary keys in sorted B-Tree indexes, so random keys land in arbitrary positions, forcing cold page reads, frequent page splits, and bloated, half-empty index pages. The problem is worse in MySQL's InnoDB, where the primary key also determines physical row order, fragmenting the entire table. The author benchmarks UUIDv4 against the time-ordered UUIDv7 standard, which places a timestamp first so new keys append near the end of the index.