A close look at UUIDv7 finds that its commonly cited benefits, including ordering, timestamps, and unguessability, are not strictly guaranteed. Only uniqueness is reliably provided.
Many blog posts promote UUIDv7 for three things: monotonically increasing IDs, a timestamp showing when an object was created, and IDs that are hard to guess. The author argues that none of these are strictly guaranteed, and that some RFC-compliant implementations break them badly. The one property that appears firmly provided is uniqueness, and with it, collision resistance.
The embedded timestamp may not match the real creation time. RFC 9562 lets implementations alter the timestamp and sets no requirement on how close it must be to the actual time. The author demonstrates this with Python's uuid.uuid7(). After the system clock was set back an hour, the generator kept its timestamp frozen and ran ahead of the clock. At high load, the gap grew without bound. The author notes that the same behavior appears in other implementations.
Ordering is also limited. Keeping IDs strictly ordered across nodes is not achievable, because clocks cannot be synchronized precisely enough. Even on a single node, a simple millisecond-based generator can produce out-of-order IDs. The author says UUIDv7 still gives a rough order that is useful, but developers should know its limits and check each implementation's behavior before relying on it.
Source: Built on Shards of Silicon
