3 ms·
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 yo
by brigadier132 2y ago
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.
- rareitem 2y agoIs there a reason to not always use v7 by default?
- davisp 2y agoInformation 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).
- rareitem 2y agoThanks, I get it. Do you have any example where leaking a timestamp could pose a security risk? I can't think of any.
- brigadier132 2y agoInformation leakage like the other person said but also if you ever move to a distributed db v7 uuids can lead to hotspots.