Hacker News Reader

My strategy is to use v4 Uuids for anything that is not inserted frequently and don't need to be ordered (think user ids) and v7 ids for things that are.

If your dataset is small the overhead from Uuids wont matter, if your dataset is large the randomness of Uuids will save your ass when you migrate to a distributed solution.

View on HN

Is there a reason to not always use v7 by default?

Information leakage since they have a timestamp component. Some people may not care, but plenty of folks do. As others have said, anything security related likely should UUIDv4. UUIDv7 is basically an engineering compromise on security (they leak a timestamp) vs performance (random reads and writes to an index aren’t as performant as localized reads and writes).

Thanks, I get it. Do you have any example where leaking a timestamp could pose a security risk? I can't think of any.

Timing attacks?

If it is public, any cases where for an entity, when it was created could be potentially sensitive information. E.g. some sort of legal documents, product, ecommerce data that could potentially reveal data to your competitors, etc.

Information leakage like the other person said but also if you ever move to a distributed db v7 uuids can lead to hotspots.

Reply on news.ycombinator.com