The Problem With UUIDs

THANK YOU PLANETSCALE FOR SPONSORING THIS VIDEO

UUID's have a time and place, but I rarely see them used correctly. I've wanted to do this rant for awhile and I'm happy I did because CUID2 is NOT a good option either 🙃

SOURCE

S/O Ph4se0n3 for the awesome edit 🙏

[einrealist]

UUID versions are NOT supposed to replace each other. They are just different implementations that address different problem domains. Once humans become a serious space-faring civilization, we probably need yet another UUID version for problems like time dillation. But such a UUID V99 is not supposed to replace V4, but to complement it. V4 can still be used within certain bounds.

[AverageUnixGirl]

"hey guys! today i will be talking about something i clearly don't understand" is a great summary of this video

[cherubinth]

I propose v9, it is the same as v4, but instead of a 4 it has a 9. This changes everything.

[flymetothemoon]

It's amazing watching somebody talk shit about something he obviously doesn't understand beyond his sponsors blog post

[xdaniels]

Oh I am still waiting on the video about PlanetScale removing the free plan and the cheaper price twice as much as competitors...

[eamonburns]

17:58 Just so you know, "I'm not telling you the difference between them, that's your problem", takes a lot more time to say than "1 byte is 8 bits"

[rikschaaf]

3:49 To my knowledge, not all versions in UUID should be seen as "the next version". Some are more like variants than versions. That's why both v1 and v4 are still used often. You could say that variant 5 is a new version of variant 3 though, because we now have better hashing algs that might have not been considered in v3. Variant 6 similarly is a new version of v1, where they reordered the date to be sortable (with v7 being a variant of that). You shouldn't think of every new --"version"-- variant being better than the previous, but that they complement each other.

[workmad]

Thinking about the different UUID variants as 'versions' that replace previous versions isn't quite right... the idea is that the different variants are used in different circumstances, so a deterministic variant is useful in some circumstances. Which is why there's a 'variant' number in it, so different variants can be checked differently.

[ChrysusTV]

"I spent years researching this to make sure I got it right. Turns out, I don't need to. Here's what my sponsor has to say." Sheeesh, DarkViper's video accurately notes a lot of key issues, like this one. Something always felt off about this channel and getting a different perspective really made things clear for me. This channel really is just regurgitation with, as you admit yourself in the first few seconds, little research.

[chepossofare]

The proble with UUIDs is that you are not using PostgreSQL.

[tarunpai]

Dude literally just read an article and nothing more. Offer some POV at least.

- I don't understand if this is really an issue with mysql or with postgres too?
- Is this even as big a problem? or is it just clickbait?
- What's the actual performance impact? there's a lot of "perf issues" thrown around with no(?) benchmarks.

[supersat]

V1 was a pretty good idea because collisions were basically guaranteed to never occur. But that was in a world where MAC addresses were guaranteed to be unique, and VMs basically killed that.

[danhorus]

This channel does read a lot of blog posts

[NicolasTroncoso]

I believe there is some confusion about sortability.
All primary keys are sortable, regardless of the value. They will fit in the B+ Tree pages with different packing sizes, and with the balancing issues described in the video.

What some people want is that records are sorted by creation time. Which is what the CUID post talks about. Don't worry about the record being naturally sorted by creation time. Use a random key to avoid hot spots, and use a createAt (or reverse CreatedAt) index if you need to scan the table the naturally created order.

[steveoc]

Javascript programmer using MySQL gives us a tech talk about the importance of performance at scale

lol

[Kazyek]

What I don't see mentioned here and should be mentioned is that your Database IDs, which you use for indexing, and referencing relationships, doesn't HAVE to be the same value you use to reference records from the API's PoV.
You can just use an integer pirmary key, then add a binary UUID field with a unique key constraint, which you don't use for joining / referencing in the database but is used at api-surface-level to identify the records.

[dijikstra]

Using a char(36) to store a uuid just seems like the worst idea every, does anyone actually do this? Postgres has a specific datatype for uuid, does MySQL still not have that?

[titbarros]

ULIDs resolve most, if not all of the problems mentioned. Is my go to now

[loganyt]

instead of PlanetScale sponsoring Theo, they should have used that money to keep reasonable free plan

[disjustice]

I generally use an integer sequence as the primary key and have an associated UUID in a unique index. The primary key is only ever used internally in the DB model and in application code. When exposing the entity in public references, the UUID is used. In addition to the issues touched on in the article, this saves us from another drawback: having to use that same 128bit UUID in foreign keys all over the DB. This goes for any globally unique identifier scheme. Because these unique identifiers need to be globally unique, they are generally so long that they are unwieldy to use as primary keys, even if they are sortable.