2026-09-09 · 6 min read · Rahul Chitturi
- uuid
- identifiers
- distributed-systems
UUIDv7 places a Unix-millisecond timestamp in the high-order bits, improving rough creation-time locality compared with fully random UUIDs. It does not guarantee a total chronological order across hosts, processes, or every identifier generated within one millisecond.
A database can therefore show equal-timestamp UUIDs in an unexpected order even when every value is valid. Network delay and transaction commit order add separate timelines.
Define which order the system needs
Distinguish generator time, event time, receipt time, commit time, and display order. If users require stable pagination or causal order, persist an explicit ordering field or sequence rather than deriving the entire contract from an identifier.
- Compare UUIDs as canonical 128-bit values
- Keep storage byte order consistent across drivers
- Do not infer sub-millisecond time without a documented scheme
- Add a deterministic tie-breaker for pagination
Handle clock rollback and bursts
Use a maintained RFC 9562 implementation with a documented policy for multiple values in one millisecond and for clocks that move backward. Different generators may use random or monotonic bits differently while remaining conforming.
Extracted timestamps are metadata supplied by the generator, not trusted audit evidence. A client can choose arbitrary UUID bits, and a compromised host can report an incorrect clock.
Inspect public identifier fixtures
Use the UUID generator for disposable samples, timestamp converter for millisecond boundaries, number-base converter to inspect high-order fields, and diff for textual or byte-order changes.
Test high-rate bursts, equal milliseconds, backward clock adjustments, process restarts, multiple hosts, database binary and text columns, driver round trips, lexicographic sorting, pagination ties, and mixed UUID versions.