A widely cited claim about UUIDv7 is that it provides monotonically increasing IDs, a helpful creation timestamp, and unguessable values. This analysis argues that none of these properties are strictly guaranteed, and that certain RFC 9562 compliant implementations violate them to an extreme degree. The only property UUIDv7 reliably provides is uniqueness, and therefore collision resistance.
The timestamp is the most misleading of the three. Superficially, embedding creation time in the ID seems to remove the need for a separate database column and provide efficient ordering through the primary index. However, the Postgres documentation warns that the extracted timestamp is not necessarily equal to the time the UUID was generated. RFC 9562 explicitly allows implementations to alter the timestamp field, and makes no guarantee about how close the clock value must be to actual time. It even permits implementations to increment the timestamp ahead of the system clock.
The Python standard library's uuid7() shows the risk in practice. If the clock jumps backwards, the generator can get stuck incrementing the timestamp, and the embedded time can race ahead of system time by an arbitrarily large amount. In testing, the gap grew steadily under load above one ID per millisecond, while lower loads merely delayed recovery.
The Python developers reportedly argued that this behavior is consistent with the RFC and other implementations, and that little can be done about a flawed system clock. Developers relying on UUIDv7 timestamps for accurate ordering or auditing should treat them with caution.
Source: Hacker News · Summarized by HeadlinesBriefing