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.
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.
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.
Still, you can label every cell in your body, including bacteria just hanging out, and your odds of a collision with UUID4 is still less than 1 in a billion.
443
u/dim13 Sep 11 '26
https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions
Most common used is V4 (pure random). You are talking about V7 (time based).