8 versions of UUID and when to use them

They should make the versions UUIDs instead of integers so that we don't make assumptions about their ordinal relationships.
- Or maybe an abbreviated hash of the text of their specifications?
- Yea, should have been V-00000000-0000-0000-0000-000000000008 instead
  
  Yes and no. They had to put the version identifier somewhere to avoid sorting problems or parsing problems, so I think that putting somewhat in the middle is a good tradeoff.

A lot of people in this thread who don't fully understand how UUIDs work...
- You're not kidding.

I didn't even know it was an ietf standard. Let aline there were versions. Apparently it's only since may this year that there are 8 versions. Before it were only 5.

Reject UUID embrace ULID.
- Interesting 👀 https://github.com/ulid/spec
- At the company I work at we use UUIDv7 but base63 encoded I believe. This gives you fairly short ids (16 chars iirc, it includes lowercase letters) that are also sortable.
  
  base63? I'd guess you'd mean base64?
  Anyways, doesn't that fuck with performance?
  I'm using this in production: RT.Comb - That still generates GUIDs, but generates them sequential over time. Gives you both the benefits of sequential ids, and also the benefits of sequential keys. I haven't had any issues or collisions with that
  
  I'll be borrowing that little trick
- I prefer CUID
  Just to clarify: Yes, I do know not all use cases are appropriate for CUID. But in general when generating ID, I'd use CUID2
- I vote for nanoid.

Personally, I always regarded UUID as one of those overcomplicated and frankly unneded "enterprisey" standards (similar to SOAP and XSD, XSLT and various other XML techonologies). After reading this article my opinion didn't change.
Also... do they even know what "version" means? That they choose that word over "type" or any other alternative says it all.
UUID Version 7 (v7) is generated from a timestamp and random data.
Use v7 if you're using the ID in a context where you want to be able to sort. For example, consider using v7 if you are using UUIDs as database keys.
Please, do NOT rely on that and just add to your tables a field with the actual timestamp.
- You don't quite understand. One of the major drawbacks of UUIDs over monotonically increasing id's is the lack of ability to sort them. Not just for manual querying, but for index operations, caching, data locality etc.
  It's very handy and is a big part of the reason why Twitter developed Snowflake IDs, which are basically like UUIDs v6 and v7.
  The UUIDs specs are quite easy to understand and definitely not "enterprisey".
  They chose "version" because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We're lucky they had the foresight to include a version number in the spec.
  
  They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.
  No they aren't. A higher version of UUID isn't "newer and better", like the word "version" implies. It's just different. It's like they called a car "vehicle version 1" and a motorbike "vehicle version 2". The common use of "version" in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.
  The talking pumpkin is 100% right that they should have used "type" or "mode" or "scheme" or something instead.
- He's not suggesting to replace timestamps (nor database sequences). They're unique identifiers, and they happen to include a timestamp.
- Uhum, why not?

There is an IETF standard for UUIDs? Do we need an IETF standard for UUIDs? I've been coding since the '90s and never thought a UUID to be complicated or contentious enough to need a standard. I guess it makes for a pretty unique icebreaker to say you've contributed to an IETF standard, if you get invited to those sort of parties.
- If you're generating UUIDs from different languages, libraries, etc. you want to be sure there doing it the same way.
  
  My face, screaming in horror, but in words instead. I've only really worked with projects in homogenous languages on the application side, so hadn't considered that. Thanks for taking the time to reply.