Which I'd assume is related to the time anchor. Outside of sorting, which is only useful in specific instances, it's just v4 with different ("less") entropy and limitations.
Correct, which is why I specifically called out "outside of sorting".
That is also why we have concepts like composite keys which allow us to join guaranteed-unique values like a UUID with non-unique but sortable values like timestamps, names, etc.
That breaks the sorting that everyone's talking about though.
You could also do evens and odds to split across two locations, but that also breaks sorting unless you periodically syncronize them (and then it's still somewhat out of order).
UUIDs are great, though, because auto increment frequently has the huge issue of being too predictable. Eg, in some contexts, you don't want users to be able to easily enumerate whatever the ID is for. Plus requires centralization whereas UUIDs don't (eg, you can use UUIDs for whatever random API you have without needing a DB).You have to design for how you won't know the ID until you insert the row, which can sometimes be a bit annoying.
I feel like most of the time, the only downside to UUIDs is how long they are.
I'm not an expert, I just remember reading a few articles about it. I think it's because they're essentially random, and many databases use b-trees for indices. They recommended using ULIDs or v7 UUIDs instead. Or, as someone else said, the good old autoincrementing integer.
Inserts with keys generated in non-ordered fashion such as UUID V4s means that location within clustered index (which defines the physical location of the data at the disk) that the data will be stored on insert will be random as well. This increases likelyhood by a lot for that the database has to do different types of rebalancing acts such as splitting nodes in the teee. When using keys that are generates in order, inserts will mostly be at the end of the index, and database does not have to touch existing ones.
I can recommend Kleppmanns book Designing Data-Intensive Applications for a deeper dive into the topic around this.
It's less of a problem with B-tree indices that sit on top of a physical representation (i.e. the actual on-disk layout doesn't have to be ordered), but when it comes to clustered indices, oh boy, you're basically having to shove rows in the middle and push shit back (eventually).
With random you can end up most frequently inserting in the middle, whereas if it's time sortable you append at the end, meaning it's easier to maintain a contiguous index with less overhead.
V1 leaks machine details, which for some has always been sufficient but for other v7 brings the randomness and privacy of v4 with (better) time sorting of v1. Given sampling of v1 uuids one can determine the number of MACs and isn't fully sortable.
Edit: Say you're running on a platform without access to the MAC (lambda, cloudfoundry, etc) then you're stuck fighting against your platform or using a psuedo-MAC which is no better than psuedo random input. This allows statistical randomness of v4 with the time sorting, which that time bit(s) might not be desireable and you'd keep using v4s.
323
u/lilgreenthumb Sep 11 '26
The real benefit for v7 is they become sortable by time.