UUIDv7 doesn't have the properties you think it does

The wire material outlines several misconceptions about the UUIDv7 specification. While blog posts often highlight benefits like uniqueness and efficient database operations, the source reveals that these properties are not strictly upheld. Certain RFC-compliant implementations of UUIDv7 fail to maintain these properties to a significant extent. The only property UUIDv7 strictly provides is uniqueness and collision resistance.

One aspect that can be beneficial is the embedded timestamp, which may eliminate the need to store creation time in a separate database column. However, this timestamp may not always correspond to the actual object creation time. RFC 9562 acknowledges that implementations can alter the timestamp field, which may not accurately reflect the system clock.

Additionally, RFC 9562 allows implementations to increment the timestamp ahead of the actual time, which could lead to future acceleration or even backward jumps if the clock jumps backward. While the counter field would need to be large (at least 12 bits) to prevent overflow, a frozen timestamp could cause the issue.

Prominent implementations like Python's UUIDv7 generator have exhibited this behavior. The generator can get stuck in an increment cycle, and the timestamp may race ahead of the system time by an arbitrary amount if the clock jumps backward. This issue has been observed in other implementations, but it might be reasonable to expect existing UUIDv7 implementations to handle system clock jumps without causing runaway behavior.

Embedding the timestamp in the ID means that sharing the ID also shares the timestamp, which may not be ideal for certain use cases. For instance, a user profile page might not disclose the creation time, but a UUIDv7 ID in the URL could unintentionally leak a high-precision timestamp. This issue is generally low on the security concerns list, but it is worth considering in specific contexts.

UUIDv7 IDs do provide some rough order, which could be suitable for certain requirements. However, the specification does not strictly guarantee strictly monotonic IDs. Single-node implementations using millisecond timestamps without a counter can easily generate out-of-order IDs. While roughly ordered IDs are still useful in many cases, it is important not to remove UUIDv7 from systems without careful consideration.