Analyzing New Unique Identifier Formats (UUIDv6, UUIDv7, and UUIDv8)

I have written before about UUIDs and other unique identifiers. As a reminder UUIDs are 128-bit identifiers that strive for unique identifier generation without requiring the generation to be done in a centralized location. The specification for UUIDs was written in 2005 and is defined in RFC 4122. This specification has served the industry fairly well. Even so there have been many other mechanisms for generating unique identifiers to try to make up for the shortcomings of the original specification. Some of these shortcomings are the following:

After reviewing 16 different community ID generation algorithms, the working group created this draft IETF document. It should be noted this is just a draft document that expires on December 25, 2022. There is a likelihood that there will be differences between the specification at the time of writing this post and what is finally accepted but it is still instructive to review (there have already been a handful of revisions of this document in the month since the draft was initially released).

The expected use case for UUIDv6 is as a drop-in replacement for UUIDv1 which offers improved DB locality. If you don’t have the requirement to keep compatibility with UUIDv1 the suggestion is to use UUIDv7 instead. The only real difference between UUIDv6 and UUIDv1 is the order of the timestamp bits. Starting with the 60-bit timestamp, the first 48 bits of the timestamp come first in the UUID (the specification splits this between time_high, and time_mid likely to keep the same terms as RFC 4122). The next 4 bits contain the version (0110 in this case for v6) and then the final 12 bits of the timestamp can be found. This leads to the following difference:

Leave a Comment