Comparing UUID v4 and v7: sortability, indexes, and privacy

By ToolSura DevTools Team, Senior Engineers · View profile

At first glance the two look interchangeable: both are 128-bit identifiers a database will happily store. The differences surface the moment you sort, index, or publish them.

What the version number encodes

Every UUID carries its own type in a few reserved bits, so software can tell versions apart on sight. Version 4 fills nearly the entire identifier with random bits, while version 7 spends the first 48 bits on a Unix millisecond timestamp and keeps the rest random. Both come from RFC 9562, the current specification that replaced the older RFC 4122 and formally added v6, v7, and v8 alongside the classic versions.

The uuid v4 vs v7 difference becomes visible the moment you look at real samples. Here is a v4 generated during research for this guide: 5859c643-66b8-412e-8a3b-7c993f5c14d5. And here is a v7 from the same minute: 01a02617-5ec9-7065-bef5-9098a7907591. The v7 opens with 01a02617 because that hex prefix is the timestamp speaking.

You can read the clock out of a v7

Those leading bits are genuinely decodable. Taking our sample v7 and reading its first six bytes as a big-endian integer yields 1787345460937: milliseconds since the Unix epoch, which is exactly August 21, 2026 at 20:51:00.937 UTC, matching the wall clock when we generated it. No lookup service, no metadata sidecar; the creation moment rides inside the identifier itself. Paste any v7 into the UUID validator to run the same decode without writing code.

That property cuts both ways. Debugging gains a free timeline, since support engineers can order events or spot suspiciously old tokens without touching a database. Privacy analysis loses a little, because publishing v7 identifiers discloses when each row came into existence. Systems exposing IDs in public URLs should decide deliberately whether that disclosure is acceptable.

The sort-order difference, measured

We put the headline claim to a direct test using Python's standard library, which ships both generators as of version 3.14 per its uuid documentation. Generating five thousand sequential v7 identifiers produced a list already in ascending lexicographic order, exactly as the timestamp prefix predicts. Five thousand sequential v4 identifiers were, predictably, scattered: string order carried no relationship to generation order.

This single property drives most of the practical debate between the two versions. Lexicographic order equals time order for v7, and databases store UUIDs as fixed-size byte strings, so index keys arrive pre-sorted.

UUID v4 vs v7 in database indexes

PostgreSQL documents its dedicated UUID functions apart from plain string columns because version bits deserve type-aware treatment.

A B-tree index prefers keys that arrive roughly in ascending order (PostgreSQL documents the mechanism) because new values append near the right edge of the tree. Fully random keys such as v4 land anywhere, forcing page splits across the whole structure and leaving pages sparsely filled; the effect on large tables is widely documented in database circles, and PostgreSQL's uuid type documentation notes that ordered variants exist precisely to improve locality for indexing. Teams migrating high-write tables from v4 to v7 typically report calmer write amplification, though the exact benefit varies with workload, fill factor, and storage engine, so measure on your own schema before promising numbers.

Collision odds compared honestly

Version 7 spends 48 bits on the clock, leaving fewer random bits than v4: roughly 74 against 122. Does that hurt uniqueness? The UUID overview on Wikipedia walks through the standard birthday-bound arithmetic, and the short answer is no at human scales. Even within a single millisecond window, v7 offers hundreds of billions of distinct values before collisions become calculable, and cross-millisecond duplicates remain astronomically unlikely. Well-built libraries also guard the same-millisecond case with the monotonicity counters that RFC 9562 recommends, and our five-thousand-value run never repeated a value.

Choosing between them

Decision guide by situation

Situation	Better fit
New database primary keys, especially high-write	v7
Public-facing identifiers where timing is sensitive	v4
Legacy systems whose parsers expect v4 only	v4 until tooling catches up
Event logs needing chronological traceability	v7
Client-side generation in browsers	Either, via crypto.randomUUID or a library

Browsers make either easy to obtain natively: the crypto.randomUUID method documented on MDN returns a v4, while server ecosystems reach v7 through maintained packages and, increasingly, standard APIs; Node's crypto module docs show what the current surface looks like.

A note on migrating existing systems: converting a populated column from v4 to v7 means regenerating identifiers, which breaks every foreign key and external reference pointing at the old values. Teams that genuinely need the change usually dual-run, writing v7 to new rows while old rows keep v4, accepting mixed versions inside one column as documented reality. Index rebuilds after bulk regeneration are another cost people forget to schedule.

Generating and checking UUIDs daily

• Create bulk samples in either version with the UUID generator
• Validate format, version, and variant bits with the UUID validator before wiring an ID into fixtures
• Decode a v7's embedded timestamp when you need to know when an identifier was born
• Keep one version per column; mixing versions inside an indexed column muddies the locality story

The pragmatic read

UUID v4 vs v7 resolves into two honest sentences. For brand-new systems writing serious rows, v7's sortable timestamps buy index health and free chronology, at the price of leaking creation time. For anything privacy-sensitive, legacy-constrained, or simply working fine today, v4 remains the battle-tested default with more randomness per identifier. Measure your own indexes if writes are heavy, and let the decision be boring.