Why Time-Ordered UUIDv7 Helps Your Indexes — and What It Costs

UUIDv7, specified in the IETF's RFC 9562 in May 2024, is a time-ordered variant of the universally unique identifier that keeps the format's advantages for decentralized generation at service scale, but sequences the most significant bits as a Unix epoch timestamp in milliseconds.

Exact RFC 9562 wording about UUIDv7 bit structure The leading timestamp makes values sortable by creation time, a property that helps locality and clustering within indexes.

How UUIDv7 clusters keys in time order

PostgreSQL's addition of the uuidv7 function in version 18 offers a way to generate the new UUID type natively. A straightforward example of a table definition shows the timestamp-leading pattern:

CREATE TABLE users (
 id uuid PRIMARY KEY DEFAULT uuidv7
 -- other columns
);

While the millisecond time part makes nearby inserts cluster together, the sub-millisecond fraction and extra random bits ensure uniqueness and break sequence. Additionally, the RFC allows generation that includes the sub-millisecond part for finer time precision.

Nerd Level Tech's exact explanation of UUIDv7 generation

Database primary keys with UUIDv7 are cryptographically random, but that absolution comes with a tradeoff. The timestamp is part of the UUID, meaning creation time is now encoded in an identifier intended to be decentralized and unguessable. This visible timing, to the millisecond, is configurable but may leak sensitive information to observers.

Another tradeoff is what happens in a database that maintains tables using both UUIDv4 and UUIDv7. No primary-source explanation of mixed-key indexing behavior was found, but tables with UUIDs of different types may mean awkward index hotspot behavior until records are split and re-indexed.

Staying centralized as UUID moves to version 7

The 2024 addition of UUIDv7 in the RFC update is significant and introduces a third time sequence variant after version 1 and 2 only used in selective Microsoft and DCE use. Unlike those, UUIDv7 integrates the traditional random pattern at the end, but the timestamp component ties it to a specific moment before the additional randomness is attached. RFC 9562 thus continues to allow PostgreSQL and other leading DBMS to generate primary keys that are easy to bring into global databases, but with benefit from index locality.

Nerd Level Tech's 2026 tutorial on this may confirm those encouraging real-world results: Nerd Level Tech's exact wording about B-tree behavior

But database builders looking for more than locality need to measure the extent of temporal visibility and index performance versus other primary keys like BIGINT. Measures of those factors were not available from imminent primary sources as of mid-2026.

For any database currently using UUIDv4 on an legacy table and seeking to replace them with the time-ordering benefits of UUIDv7, the process needs careful treatment of indexes and persistence that were built, under the assumption of the UUIDv4's "random" behavior.

Overall, UUIDv7 is the emerging default choice for new databases because it keeps the decentralized benefits of UUIDs and brings insertion locality, but that gain in locality and database performance comes with observable timestamps and some migration complexity.