UUID v7

TechniqueIdentifiers and OrderingSeniorStaffUpdated Nov 10, 2026

Timestamp-prefixed UUID: sortable, monotonic, still 128-bit and globally unique.

When to Use UUID v7

When you want UUID's uniqueness guarantees but also need DB index locality. UUID v4 randomness wrecks B-tree caches; v7 keeps recent writes hot.

In Practice

Postgres 16 partitioning works far better with UUID v7 keys than v4 because adjacent inserts land on the same page. Many ORMs (Object-Relational Mappers like Prisma, Drizzle) recommend v7 for new tables.

How UUID v7 Comes Up in Interviews

Scenario

Your Postgres table uses UUID v4 primary keys and the B-tree cache hit rate is awful because inserts land in random pages. You want to keep UUID's global uniqueness but recover index locality. What do you switch to?

UUID v7 prefixes the 128-bit ID with a millisecond timestamp so sequential inserts land on adjacent B-tree pages, keeping the working set hot. Snowflake would also work but is only 64-bit and not a drop-in UUID replacement.

UUID v7 is the answer to 'we want UUIDs but our B-tree cache hit rate is terrible.' The first 48 bits are a Unix millisecond timestamp, so sequential inserts cluster on adjacent index pages and the working set stays hot. UUID v4's pure randomness scatters inserts across the entire index, causing constant page faults, workloads have measured 5-10x throughput differences between v4 and v7 PKs on Postgres at scale. Postgres 16's native UUID v7 support and the recommendations from Prisma, Drizzle, and Ecto all reflect this. Snowflake would also fix the locality problem but isn't 128-bit, so it's not a drop-in replacement for existing UUID schemas.