I spent a while wondering why inserts on a particular table were getting slower as it grew. The table had a UUID v4 primary key and a few indexes. The data wasn't huge - a few million rows - but write performance was noticeably degrading. The problem wasn't the query. It was the UUID. What's actually happening UUID v4 is random by design. Every new ID lands at a completely unpredictable position in the B-tree index. So every insert causes the database to find that random position, potentially split a page to make room, and rebalance. Do this millions of times and you end up with a fragmented index, lots of wasted space, and slower writes. With an auto-incrementing integer, every new row goes at the end. No splits. No rebalancing. The index stays tight. UUID v4 throws all of that away. UUID v7 fixes it UUID v7 was standardised in RFC 9562 (May 2024). The important bit: the first 48 bits are a Unix millisecond timestamp.…