Hacker News Reader

Comment by maxloh | Hacker News Reader

What is the use case for UUIDv4/v7 when bigint is faster and uses less storage space?

UUIDs are nice for exposing them outside, such as:

1) exposing in URLs (you can't scrape all data by iterating over IDs)

2) passing them around between microservices/systems (less confusion where an ID comes from when debugging/doing tech support, because you can check the ID in a few tables and be 100% sure that's exactly what you are looking for, because IDs are globally unique, unlike bigints)

3) useful in situations when data from several servers or DB shards is eventually aggregaged in one place (for example, for analytics) - with bigints you'd have collisions

you can generate them anywhere, and not guess others

Postgres can return the id to you that it generates.

...which means you need a round-trip to the database before doing anything else. That's latency you can avoid with client-side predictable (or determined) UUID's.

Whether you should do anything else before the data has been persisted is a totally different discussion.

Unless you’re doing some wild async YOLO, you’re already waiting for the DB to send back success; adding a max of 8 bytes into that is highly likely to fit into the same TCP packet and thus add little to no overhead.

If you are doing async writes, as you alluded to, why bother with RDBMS in the first place? ACID is out the window.

Not so in all cases.

- insert/then retrieve ID can easily result in duplicate records in some edge cases, and won’t necessarily be able to be easily fixed either. the inserted record doesn’t have a global ID until it’s inserted.

Can this generally be fixed using good transactions semantics? Yes usually. But it’s expensive. And in many cases you’ll have to default to failing writes instead of eventually consistent behavior.

- CRDT type behavior works better when things have a known valid unique ID from the get go. insert/update/ignore can happen quickly and easily without two way communication and in bulk, and edge cases have more easily modelable ‘eventual consistency’.

- generating unique IDs in the database forces serialization of certain processes in the database, which can cause scaling issues and high latency.

For instance, using the DB to create unique request IDs for web or API requests? Asking for problems.

Generating UUIDs for them at request time, and then putting those IDs where needed when later correlation/tracking is desirable? Much better.

Same can apply for other object ID creation, when there aren’t other natural keys that need to be checked first.

If you mean client like client, and not application server, don't do that (assuming you want to use uuidv7). Client generated IDs mean they can lie in the timestamp bits. Only use client generated ids as an idempotency key.

uuid you can generate the id in the client and send that knowing (hoping) it won't conflict

Reply on news.ycombinator.com