Current state of UUID v6 standard

[filips123]

What's the current state of UUID v6 draft?

I think that UUID v6 (or other standardized alternative for UUIDs ordered by time) would be very important and useful for usage in various data storage systems like databases. However, there are still some "concerns and TODOs" listed in this repository, and IETF draft will expire in less than a month (on August 27, 2020). There also don't seem to be any big changes about UUID v6 draft for a few months.

Does this mean draft will be abandoned? If so, will there be any alternative in the near future? What should developers that want to use UUID-like primary keys and identifiers in databases without loosing performance due to unordered bits of current UUID versions?

Also, in case if draft expires, what does this mean? Can it be then resubmitted when it is ready?

[bradleypeabody]

Overall I still think UUIDv6 is a good idea, I just haven't had a chance to work on it in a while. If it expires it can certainly be resubmitted. There are a lot of little pieces to the puzzle to get interest and agreement on in order for it to result in an actual RFC. One of the next steps is to fill out the README with more info on each of the points. In my past conversations on this there are many different ideas on how different aspects could be approached, some of them more workable than others. Documenting the various tradeoffs is an important part of putting together a complete UUID draft. I hope to be able to get back to this soon and any feedback or assistance on it is also welcome.

[filips123]

Thanks for response. I agree that it is important to document tradeoffs and alternative solutions.

However, I think that some of them are out of scope for UUID v6 standard. For example, length and text encoding specifications could be very useful, but are not really related specifically to UUID v6 standard because they could also be used with existing UUID versions. I don't know how RFCs are expected to be structured, but IMO this topics should be part of separate UUID RFC, or this draft should be renamed/moved to reflect what it does. But some other things should probably be part of this specific draft.

Also, one other thing that would be useful to document is performance difference/impact between old-school auto increments, existing UUID versions and UUID v6 for usage as primary keys in various databases, database relations and other storage applications, stored as just HEX text with dashes, in binary or other encodings.

[bradleypeabody]

Thanks and I get what you mean.

I do think the points you bring up are a good example of why an organized document is needed, clearly laying out what the current position/decision is as regards this RFC proposal on each point. For example, I see what you mean on the text encoding being a separate issue, but at the same time the existing RFC does specify both the binary layout and the text specs so there's precedent for that. And also with all of the effort required to actually make an RFC get published, I think it's important for it to contain everything that will solve the most common problems - i.e. IMO, the decision about if text formats should be included should be based on if it helps solve the real-world problems related to using UUIDs in the wild. And, while I'm not dead-set on this, the reason I included the text formats in the draft was because I thought it was important enough.

The performance data would definitely be interesting and useful to know. Someone would need to build out some benchmarks for that and it would be a welcome contribution for sure. There will certainly be some variations in this based on tradeoffs of how it's implemented. E.g. storing UUIDs in binary might be faster but then be more of a hassle for developers to deal with mangling them back and forth in SQL. This sort of concern is important to discuss and be aware of, but then it's impact on the final spec will probably something very simple e.g. "implementations can decide to store UUIDs internally in whatever format they want, the options are..."

I will try to carve out some more time to fill out the README of this repo with the data I have. Contributions are definitely welcome in the form of a PR that we can discuss and the hopefully merge.