UUIDv4 vs. UUIDv7: Why Order Matters for Database Indexes

UUIDv4 and UUIDv7 are both 128-bit identifiers, but they organize their bits differently. UUIDv4 uses random data, while UUIDv7 begins with a millisecond timestamp, followed by random data or optional ordering components. This makes UUIDv7 approximately chronological when sorted.

The main database advantage is better locality in B-tree indexes.

With UUIDv4, new keys land throughout the index. Inserts can touch many different pages, increasing cache misses and disk activity. Splitting full pages can also leave space unevenly utilized.

With UUIDv7, newly generated keys usually land near the end of the index. As a result, inserts repeatedly access a smaller set of pages. This can provide:

  • Better cache efficiency, because recently accessed pages are reused.
  • Less scattered I/O, especially when the index exceeds available memory.
  • Better page utilization and potentially fewer disruptive page splits.

These are workload-dependent benefits, not guaranteed speedups. RFC 9562 explicitly identifies poor database-index locality as a limitation of random UUIDs.

UUIDv7 still occupies 16 bytes and exposes its generation timestamp. It also does not guarantee exact creation order across machines or within the same millisecond.