Random UUID v4 keys scatter writes across an index. UUID v7 keeps global uniqueness while sorting by time, making it a strong option for many write-heavy tables.
For implementation context, continue with UUID v7, Database Guide, and UUID vs ULID. These pages cover the closest generator, comparison, validation or storage decisions without repeating this guide.
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 18 includes uuidv7(), Python 3.14 includes uuid.uuid7(), and maintained packages cover many other runtimes. Support still varies by deployed version, so verify the exact database, runtime and ORM in your stack before choosing where generation belongs.
v4: 4f8b1a9a-7c2d-4a59-9b9f-1c2d2f7e5a01 (fully random)
v7: 018f2f7a-07b2-7d6e-9c37-43e1577b8b44 (timestamp-first, then random)
^^^^^^^^^^^^ leading bits encode creation timeWhen 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.