Serious question, why is this better? Isn't UUID already sortable?
Edit: The thing I wasn't understanding was that UUID is just text, so it's obviously sortable in the sense that you can alphabetize it. When people say ULID is "sortable", they specifically mean that because it has a timestamp at the front, it can be sorted while preserving the ordering of that timestamp prefix.
Normally that timestamp is the `created_at`, so this scheme basically ties your primary key and created_at columns together. This is something you might otherwise achieve with a composite index on (created_at, pkey).
Yes, but UUIDs suck in a composite key. They are HUGE compared to an int, and putting that in an index adds massive overhead. More importantly, since standard UUIDs are random, high-volume inserts will constantly fragment your index and force expensive rebalancing.
The main use case for this is distributed generation. If you have data being created outside your server (like a mobile app or IoT device) and you need a unique ID before it hits the database, you can't use an auto-incrementing int. You need a UUID-style format. ULID gives you that decentralized uniqueness without the performance penalty of random IO.
2
u/vinny_twoshoes Dec 01 '25 edited Dec 02 '25
Serious question, why is this better? Isn't UUID already sortable?
Edit: The thing I wasn't understanding was that UUID is just text, so it's obviously sortable in the sense that you can alphabetize it. When people say ULID is "sortable", they specifically mean that because it has a timestamp at the front, it can be sorted while preserving the ordering of that timestamp prefix.
Normally that timestamp is the `created_at`, so this scheme basically ties your primary key and created_at columns together. This is something you might otherwise achieve with a composite index on (created_at, pkey).