UUID Generator

Databases

Why UUID v7 Is Becoming the Default Primary Key in 2026

UUID v7 combines global uniqueness with time ordering, fixing the write-amplification problem that made random UUID v4 a poor primary key. Here is why teams are switching.

By UUID Generator TeamPublished Updated Reviewed for accuracy

Random UUID v4 keys scatter writes across an index. UUID v7 keeps global uniqueness while sorting by time, which is why it is quickly becoming the default choice for new tables.

The problem UUID v7 solves

For years the default identifier debate was simple: auto-increment integers for single-database speed, or random UUID v4 when you needed globally unique IDs that could be generated anywhere. UUID v4 solved uniqueness but introduced a quiet performance cost. Because its bits are random, every insert lands in a random position of the primary-key index, which fragments B-tree pages and hurts cache locality on write-heavy tables.

UUID v7 removes that trade-off. It places a Unix millisecond timestamp in the leading bits, followed by random data. New rows therefore sort near other recent rows, so inserts append to the hot end of the index instead of scattering. You keep decentralized, collision-resistant generation while regaining the insert pattern that databases love.

What changed to make v7 practical

UUID v7 is part of RFC 9562, the 2024 update that modernized the UUID standard. Since then, native or library support has landed across the ecosystem: PostgreSQL functions, ORM helpers, and standard-library or well-maintained packages in most languages. That maturity is the tipping point. A version is only a good default once you can generate it reliably everywhere, and in 2026 you can.

v4: 4f8b1a9a-7c2d-4a59-9b9f-1c2d2f7e5a01   (fully random)
v7: 018f2f7a-07b2-7d6e-9c37-43e1577b8b44   (timestamp-first, then random)
    ^^^^^^^^^^^^ leading bits encode creation time

When UUID v7 is the right default

Reach for UUID v7 when rows are created continuously and you want them to index well: primary keys, event logs, audit trails, inbox/outbox tables and time-series-adjacent data. It is also friendlier for pagination and debugging because identifiers move in the same direction as time.

The one caveat is that a v7 value reveals roughly when it was created. If that timing is sensitive for a public identifier, prefer UUID v4, or keep an ordered v7 primary key internally while exposing a separate opaque public ID.

How to adopt it without a big migration

You rarely need to rewrite existing keys. Start using UUID v7 for new tables and new columns, keep old identifiers as they are, and let the two coexist. Both are valid UUIDs, so foreign keys, validation and storage types do not change. Generate a few with the tool on this site to see the shape, then wire generation into your service or database layer.

Open the UUID generator More articles

FAQ

Why UUID v7 Is Becoming the Default Primary Key in 2026 questions

Is UUID v7 better than UUID v4 for primary keys?

For write-heavy tables, usually yes. UUID v7 sorts by creation time so inserts stay local in the index, while UUID v4 scatters them. UUID v4 is still fine for smaller tables or when you must hide creation time.

Does UUID v7 replace auto-increment IDs?

It can. UUID v7 gives you ordered, index-friendly keys that can also be generated outside the database, which auto-increment cannot. Auto-increment is still simplest when all rows come from one database and you never expose the ID.

Why UUID v7 Is the New Default Primary Key (2026)