Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

sotergreco.com

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#11

Post by Dylan16807 »

wodenokoto wrote: post #5

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?

> 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.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#12

Post by pants2 »

I worked on a huge backend system that used ULIDs for everything. I liked them slightly better than UUIDs in general, but nobody coming in or using our system knew what ULIDs were, so we constantly had to explain what they were. If we used UUIDs there would have been far less confusion. In conclusion: Just use UUIDs.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#14

Post by dagss »

willvarfar wrote: post #9

The main driver behind lexically sortable identifiers is that you generally insert into databases in time order so if your ids are sorted by time then you are appending to the end of the table. If, on the other hand, your ids are random (e.g. the prevalent UUIDv4) then your database is spending all it's time shuffling everything around to insert your new rows in the middle of everything. Once you have time-based iden…

But if you for instance use MS SQL and the uniqueidentifier type, sorted UUIDv7 is not sorted im the database because MS SQL swapsnthe bytes around. So ULID (stored as binary(16)) is an advantage in that case to avoid making that mistake.

I really like that ULID looks differentt from UUIDv4. UUIDv7 is something sorted that on the surface looks like it will be random and is mixed with random IDs etc..

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#15

Post by erik_seaberg »

wodenokoto wrote: post #5

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?

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.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#16

Post by cbsmith »

willvarfar wrote: post #9

The main driver behind lexically sortable identifiers is that you generally insert into databases in time order so if your ids are sorted by time then you are appending to the end of the table. If, on the other hand, your ids are random (e.g. the prevalent UUIDv4) then your database is spending all it's time shuffling everything around to insert your new rows in the middle of everything. Once you have time-based iden…

What drives me nuts is people storing uuids in databases as hex strings. They're bytes, and if you do it right, even the type 1's are lexigraphically sortable.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#17

Post by cbsmith »

codetrotter wrote: post #7
wodenokoto wrote: post #5

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?

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 t…

Cassandra seemed to have no problem using type1 UUIDs for this.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#18

Post by cbsmith »

vbezhenar wrote: post #4

At this point I think that ideal setup is to use numerical id for primary and foreign keys and maintaining a separate uuid field for everything else. The reason being that index size matters a lot (for caches and other things) and index size depends on underlying field size, obviously. Whether to use UUID or ULID is depends on tooling. While it's not hard to write ascending UUID generator and I did it myself few time…

Or you can just store the UUIDs as bytes like the almighty intended.

Re: Why Choose ULIDs over Traditional UUIDs or IDs for Database Identification?

#20

Post by cbsmith »

mattbillenstein wrote: post #8

I've been doing something that includes a type character as the first character - followed by 11 random base58 digits. This allows > 2^64 possible ids and a type in ~12 bytes. I occasionally wish they were ordered, but most of my tables usually have a 'created_at' field anyway should ordering matter. I feel like uuid / ulid are just overkill for most situations - and they're long and kinda ugly imo.

Isn't that basically a type 4 UUID that you truncated the last 4 bytes from?
Post reply on HN