4 ms·

Did the article provide any reason for ULID over UUID? - it’s slightly more complex than UUID, but not enough to be a problem - it’s sortable (in time?) which

Did the article provide any reason for ULID over UUID? - it’s slightly more complex than UUID, but not enough to be a problem - it’s sortable (in time?) which UUID can also be (but usually recommended not to be) - it can produce slightly more ids per second, but not enough to make a difference. So, it’s a tie, a tie and a tie. Why would you switch?

lazyasciiart 2y ago
It jumps straight to “I’m not going to list all the reasons”. Ok, maybe just the biggest one or two reasons? Is lexicographer sorting that helpful?
codetrotter 2y ago
There is a draft for a UUID variant called v7 which is basically the same like ulid It is absolutely valid In particular when you want ids to be in mostly ascending order but where you can’t use an auto incrementing int It’s sortable is a key feature because it can help make searching tables more efficient in situations where the data is naturally tied to the time at which the entry was made and your queries relate to time also For example, if you append rows with ulid or uuid v7, then you can binary search the records in the file without first sorting or making an extra index of the ids as they are already for the most part in ascending order
- cbsmith 2y ago
  Cassandra seemed to have no problem using type1 UUIDs for this.
Dylan16807 2y ago
> it’s sortable (in time?) which UUID can also be (but usually recommended not to be) It gives you the sortable parts without the "recommended not to" parts.
erik_seaberg 2y ago
If your team hasn't engineered in monotonically increasing distributed clocks, the results of sorting are only partly correct. I'd rather not promote an option we can't rely on.
- russell_h 2y ago
  They’re only partially correct no matter what. The timestamp in a ULID has only has millisecond resolution, so two IDs generated in the same millisecond, even within the same process, will be randomly ordered. In practice though there are a lot of advantages to having approximately-time-ordered IDs, and I’ve found the pitfalls easy enough to avoid.
  - MarceColl 2y ago
    The ULID spec has the weird "first generate a random number and all successive calls within the same millisecond just increment the previous number by 1", which tries to solve this somewhat at the expense of now needing to lock, making ULID generation sequential within the same process.
    - evgpbfhnr 2y ago
      That probably isn't something good for everyone, it makes trying to guess ids on a busy system so much easier than 60ish bits of random data (just get an id, try to add or remove 1, and if someone else happened to generate another id the same millisecond you've just found it?) Whether the id is secret or not is a debatable choice, but there's no reason to make it easily guessable; at least that increment should be random with a somewhat large stride... But in general anyway in a distributed system network latency etc will mean things are just "mostly sorted" which is good enough, keeping the last few inserts in order is much easier than reshuffling the whole db/index all the time
    - russell_h 2y ago
      You’re right, good catch, I completely missed that.
- 2y ago
cuu508 2y ago
That was left as an exercise for the reader :-/ > I am not going to cover all the reasons why Ulid is better, but in the end, it's up to your personal preference.

lazyasciiart 2y ago

It jumps straight to “I’m not going to list all the reasons”. Ok, maybe just the biggest one or two reasons? Is lexicographer sorting that helpful?

codetrotter 2y ago

There is a draft for a UUID variant called v7 which is basically the same like ulid It is absolutely valid In particular when you want ids to be in mostly ascending order but where you can’t use an auto incrementing int It’s sortable is a key feature because it can help make searching tables more efficient in situations where the data is naturally tied to the time at which the entry was made and your queries relate to time also For example, if you append rows with ulid or uuid v7, then you can binary search the records in the file without first sorting or making an extra index of the ids as they are already for the most part in ascending order

cbsmith 2y ago
Cassandra seemed to have no problem using type1 UUIDs for this.

Dylan16807 2y ago

> it’s sortable (in time?) which UUID can also be (but usually recommended not to be) It gives you the sortable parts without the "recommended not to" parts.

erik_seaberg 2y ago

If your team hasn't engineered in monotonically increasing distributed clocks, the results of sorting are only partly correct. I'd rather not promote an option we can't rely on.

russell_h 2y ago
They’re only partially correct no matter what. The timestamp in a ULID has only has millisecond resolution, so two IDs generated in the same millisecond, even within the same process, will be randomly ordered. In practice though there are a lot of advantages to having approximately-time-ordered IDs, and I’ve found the pitfalls easy enough to avoid.
- MarceColl 2y ago
  The ULID spec has the weird "first generate a random number and all successive calls within the same millisecond just increment the previous number by 1", which tries to solve this somewhat at the expense of now needing to lock, making ULID generation sequential within the same process.
  - evgpbfhnr 2y ago
    That probably isn't something good for everyone, it makes trying to guess ids on a busy system so much easier than 60ish bits of random data (just get an id, try to add or remove 1, and if someone else happened to generate another id the same millisecond you've just found it?) Whether the id is secret or not is a debatable choice, but there's no reason to make it easily guessable; at least that increment should be random with a somewhat large stride... But in general anyway in a distributed system network latency etc will mean things are just "mostly sorted" which is good enough, keeping the last few inserts in order is much easier than reshuffling the whole db/index all the time
  - russell_h 2y ago
    You’re right, good catch, I completely missed that.
2y ago

cuu508 2y ago

That was left as an exercise for the reader :-/ > I am not going to cover all the reasons why Ulid is better, but in the end, it's up to your personal preference.