UUID v7: Time-Ordered IDs Without Surrendering Randomness
Database-friendly identifiers often benefit from roughly chronological clustering. UUID v7 standardizes that pattern inside the familiar 128-bit UUID shape—useful for B-tree indexes and log correlation when you accept embedded timestamps.
Structure: time prefix plus random tail
The leading bits carry millisecond precision time; the remainder stays random to reduce collision risk under concurrency. Compare with older UUID versions in our UUID overview before migrating primary keys.
Epoch alignment and observability
When debugging, map IDs back to wall clocks with Unix timestamp tools—especially across regions and daylight saving transitions where human-readable logs mislead.
JSON payloads and API contracts
IDs appear in JSON as strings—keep formatting consistent with JSON best practices and validate schemas so clients never treat UUIDs as numbers.
Monotonicity within a millisecond
The spec leaves room for sub-millisecond sequence counters—two inserts in the same millisecond should still increase lexicographically when you need strict ordering for replication. Verify your library implements this if you stream high-QPS events into LSM storage.
Distributed generators and coordination
Each service instance can mint v7 independently; collisions remain astronomically unlikely if random bits are sound. Avoid centralized ID servers unless you need global sequence guarantees—those become single points of failure and latency bottlenecks.
Migrations from auto-increment or Snowflake IDs
Backfill tables with dual-write periods: keep legacy BIGINT foreign keys until consumers switch. Compare ordering semantics in analytics—time-based IDs sort like timestamps but are not contiguous integers for human operators.
Recommended tools
Generate sample v4/v7-style IDs for tests.
Correlate sortable IDs with human-readable time.
Reason about random tails versus pure v4 IDs.
Compare API responses when ID formats change.
Related guides
Frequently Asked Questions
Why is UUID v7 sortable?
It embeds a Unix timestamp in the leading bits so newer IDs generally sort after older ones in lexicographic order.
Does sortability mean global ordering?
Roughly by creation time, but clock skew and concurrent generators can still collide—use DB constraints and monitors.
How do timestamps relate to UUID v7?
You can cross-check UUID order with epoch converters and logs—pair with timestamp tools when debugging.
When prefer v4 over v7?
Pure random v4 avoids time leakage; choose based on privacy, indexing strategy, and storage engine behavior.
Do UUID v7 values leak business volume?
Rough creation order is visible—if that is sensitive, stick to v4 or opaque server-side surrogates.
How do databases index UUID v7?
B-tree friendly insertion reduces page splits versus random v4—still monitor hot shards when traffic spikes.
Wrapping up
UUID v7 trades a little temporal structure for friendlier indexing—choose it with eyes open on privacy, collision handling, and storage engine behavior.
UUID Generator →