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. Because time only moves forward, v7 UUIDs sort chronologically - new ones are always greater than old ones.

The database sees the same sequential insertion pattern it gets from an integer primary key. No fragmentation. You keep all the benefits of a UUID (globally unique, no central registry, works across distributed systems) without the index penalty.

It looks identical to v4:

018f6e3a-2b4c-7d8e-9f0a-1b2c3d4e5f6a

Drop-in replacement. Same format, same length.

When v4 is still the right call

If the ID is exposed publicly and you don't want to leak when a record was created - use v4. The timestamp in v7 is extractable, which can be a privacy concern for things like user account IDs.

For internal records, order IDs, event logs, anything where sequential ordering is fine - v7.

Language support

Most stacks have it now. Node.js uuid package has uuid.v7() since v9. Python 3.14 has it in stdlib, or use the uuid7 package. ramsey/uuid in PHP, google/uuid in Go, Prisma has uuid(7) as a default option. PostgreSQL has the pg_uuidv7 extension.

If you're starting a new project, just use v7. If you have an existing table with v4, you don't need to migrate - new rows can switch immediately and the index tightens up gradually as old pages get rewritten.

For generating both versions with various formatting options, datatoolkit.net/uuid does the job. There's also a more detailed writeup on the performance implications at datatoolkit.net/learn/uuid-v4-vs-v7.