Your B-tree indexes hate UUID v4. They've hated it for years. You probably haven't noticed because the slowdown is gradual — until your table hits 10 million rows and inserts start taking 200ms instead of 5ms. UUIDv7 fixes this. RFC 9562 made it official in May 2024. PostgreSQL 18 ships native support. MySQL 8.4 has a helper. Most ORM and language libraries added v7 in 2024–2025. By 2026, v4 should be the exception, not the default . This post is the "why", the "when", and the "how to migrate without breaking things". The Problem with v4 A v4 UUID is 122 bits of pure randomness: e7d1a8c4-9fe5-4a32-8c7e-3f9d2e8a1c4b Looks fine. Random is what we want, right? Yes — for things that need to be unguessable . No — for things that go into a B-tree index. Why B-trees hate randomness Database indexes (B-tree, which is what Postgres, MySQL, SQLite, MSSQL all use for primary keys by default) work best when new entries arrive in roughly sorted order .…