UUID Formats 6–8
IETF (via Hacker News):
The fact that UUIDs can be used to create unique, reasonably short values in distributed systems without requiring synchronization makes them a good alternative, but UUID versions 1-5 lack certain other desirable characteristics:
- Non-time-ordered UUID versions such as UUIDv4 have poor database index locality. Meaning new values created in succession are not close to each other in the index and thus require inserts to be performed at random locations. The negative performance effects of which on common structures used for this (B-tree and its variants) can be dramatic.
- The 100-nanosecond, Gregorian epoch used in UUIDv1 timestamps is uncommon and difficult to represent accurately using a standard number format such as [IEEE754].
- Introspection/parsing is required to order by time sequence; as opposed to being able to perform a simple byte-by-byte comparison.
[…]
An inspection of these implementations and the issues described above has led to this document which attempts to adapt UUIDs to address these issues.
This is the working area for the IETF UUIDREV Working Group Internet-Draft, “A Universally Unique IDentifier (UUID) URN Namespace”.
Previously:
Update (2023-10-30): Buildkite (via Hacker News):
The upcoming UUIDv7 standard offers the best of both worlds; its time-ordered UUID primary keys can be utilized for indexing and external use. This blog post will take you on the journey Buildkite took that led to our eventual adoption of UUIDv7 as the primary key of choice. We’ll explore the tradeoffs of database indexes; from sequential integers, randomly generated UUIDs, through to time-based identifiers.
