GoKawiilRFC 9562 allows UUIDv7 timestamps to drift from actual creation time
A blog post by Robert Alexander examines UUIDv7, the time-ordered UUID format, and argues that its commonly assumed properties—monotonic ordering, accurate embedded timestamps, and unguessability—are not strictly guaranteed. He cites RFC 9562 itself, which permits implementations to alter the timestamp field rather than deriving it strictly from the system clock, and notes Postgres documentation warning that extracted timestamps may not match actual generation time. According to the post, the only property UUIDv7 reliably provides is uniqueness and collision resistance.
GoKawiil's interpretation of the reporting above, not reported fact.
Many developers use UUIDv7 under the assumption that embedding a timestamp lets them skip a separate creation-time column or rely on sort order for chronological queries, which this analysis suggests could be unsafe in some implementations. If timestamps can be deliberately offset ahead of real time per the spec, systems relying on UUIDv7 for ordering or auditing could produce misleading results. This could push engineering teams to re-evaluate whether UUIDv7 suits use cases beyond simple deduplication.
- UUIDv7's embedded timestamp is not guaranteed to reflect actual object creation time.
- RFC 9562 explicitly allows implementations to alter or advance the timestamp field.
- Uniqueness and collision resistance appear to be the only properties UUIDv7 reliably guarantees, according to the post.
Source: alexsci.com, 2026-10-23
Published there as: “UUIDv7 doesn't have the properties you think it does”
Read the original report → The summary and analysis above are GoKawiil's own, written from reporting by the source above. Facts and quotes belong to the original publisher.