Tim FevensNov 11, 2022

@ravetracer_22 @ramsey @shocm Opened the thread to ask about this. We've all been told that searching is faster with int, so would using UUID or ULID end up with slower queries?

I'm guessing that performance is comparable, with a large amount of data?

Show threadEric Van Johnson
@tfevens @ravetracer_22 @ramsey Honestly, not sure I've had a big enough application to say I see a difference. Obviously the more data the longer the query will be in theory. But what is the trade-off? Now you have a truly portable ID that can go to other systems and is a true identifier for the record it represents. Think about having a UUID in a completely different system that points to a record in another system. No collision of IDs. (or less of a chance technically)
Nov 11, 2022 at 1:16amWeb
Show threadTim FevensNov 11, 2022
@shocm @ravetracer_22 @ramsey
👍 For the record - I've never worked with data large enough that would cause a noticeable change. It was just something I had thought of when thinking about int vs uuid/ulid.
Show threadBen RamseyNov 11, 2022

@tfevens @shocm @ravetracer_22 If you're worried about space, use the binary (16-byte) form of the UUID/ULID. If you're worried about scattering/sorting, use a v6 or v7 UUID or a ULID. A v7 UUID is a ULID that follows the UUID spec.

I've not done benchmarks to compare differences between int and UUID/ULID as primary keys.

Show threadBen RamseyNov 11, 2022
@tfevens @shocm @ravetracer_22 Technically, you could represent any UUID as a ULID, using the Crockford Base-32 encoding, but they wouldn't be sortable or have a meaningful timestamp portion.