UUIDv7 has become the default recommendation for modern ID generation, with blog posts and conference talks selling a tidy bundle: monotonically increasing IDs, embedded creation timestamps, and unguessability. A detailed technical audit of the RFC 9562 specification and real-world implementations finds that none of these properties are strictly guaranteed. The only ironclad promise is uniqueness. The timestamp problem is more than academic. RFC 9562 explicitly permits implementations to alter the timestamp field, using values not strictly derived from the system clock. Section 6.1 states: "This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time." Section 6.2 allows implementations to increment the timestamp ahead of actual time when counters overflow. The Postgres docs for uuidextracttimestamp already warn that extracted timestamps may not match generation time. Python 3.14's standard library uuid.uuid7() demonstrates the failure mode concretely. When a system clock jumps backward — a well-documented real-world occurrence — the generator refuses to emit earlier timestamps but enters a runaway cycle. Under load above one ID per millisecond, the embedded timestamp accelerates into the future without bound. A one-hour clock setback produced timestamps racing ahead by 3,600+ seconds and climbing at roughly 100 seconds per 100,000 IDs generated. Python developers have acknowledged this behavior as RFC-compliant and present in other implementations. Monotonicity fares no better. Strict global ordering across distributed nodes was proven impossible in the 1970s, a result that led to vector clocks. UUIDv7 claims monotonic ordering without the machinery to deliver it. Even on a single node with a single implementation, IDs are not strictly monotonic — implementations using millisecond timestamps without counters trivially produce out-of-order IDs inside a simple for loop. The RFC provides no mechanism to ensure strict monotonic increase. The persistent-state gap compounds the problem. To safely handle backward clock jumps, a generator must write its last-used timestamp to persistent storage and read it back after restarts. The author examined multiple UUIDv7 implementations and found none that do this. Process restarts after clock anomalies silently produce out-of-order IDs, and clocks set to future dates create a different trap: the last-used-timestamp guard forces continued use of incorrect timestamps until the system clock catches up, potentially triggering counter rollovers. The practical upshot is that UUIDv7 is best understood as a menu of implementation choices, not a fixed contract. The RFC gives implementers wide latitude, and different implementations make different tradeoffs. Distributed systems running multiple implementations across subsystems may get different property sets from each. The author provides a six-question checklist for evaluating any UUIDv7 implementation: RFC compliance, additional guarantees, guarantee limits, clock accuracy assumptions, timestamp alteration conditions, and guessability profile. This is not a call to rip UUIDv7 out of production systems. Roughly ordered, roughly timestamped, unique IDs remain useful. The warning is against treating RFC compliance as a guarantee of the properties most developers assume they're getting. The gap between the marketing pitch and the specification is wide enough to cause real bugs in systems that depend on strict ordering or accurate embedded timestamps.
