UUIDv7 doesn't have the properties you think it does

UUIDv7 is often promoted as providing increasing identifiers, creation timestamps, and hard-to-guess values, but its specification permits implementations to trade timestamp accuracy for ordering and leaves many behaviors optional. The embedded time may therefore differ substantially from actual creation time. The author highlights Python’s generator: after a system clock is moved backward, it avoids decreasing timestamps, but under sustained generation above roughly one ID per millisecond, its timestamp can continue racing into the future. Counter overflow, especially while a timestamp is frozen, can worsen this. Sharing a UUIDv7 can also reveal a high-precision creation-time estimate, which may matter when account age or activity timing is sensitive.

UUIDv7 does not guarantee strict chronological ordering, either. Unsynchronized clocks make global ordering impossible to ensure, while even a single-node implementation can produce out-of-order IDs if it relies on millisecond timestamps without counters. Persisting the last timestamp could help after a restart, but implementations generally do not do so, and clock corrections can create further complications. Rough ordering remains useful, so the argument is not to abandon UUIDv7, but to stop treating its advertised advantages as universal guarantees. Implementations vary and can change while remaining RFC-compliant; uniqueness and collision resistance are the dependable properties. Users should assess each generator’s guarantees and limits, including clock assumptions, timestamp adjustments, restart behavior, and how predictable its IDs are.