3 ms·
The is article is about a solution in search of a problem, a classic premature optimization issue. UUIDv4 is perfectly fine for many use cases, including small
by ivan_gammel 11mo ago
The is article is about a solution in search of a problem, a classic premature optimization issue. UUIDv4 is perfectly fine for many use cases, including small databases. Performance argument must be considered when there’s a problem with performance on the horizon. Other considerations may be and very often superior to that.
- sagarm 11mo agoIt's not really feasible to rekey your UUIDv4 keyed database to int64s after the fact, imo. Sure your new tables could be integer-keyed, but the bulk of your storage will be UUID (and UUIDv4, if that's what you started with) for a very long time
- ivan_gammel 11mo agoYes, sure. My point is, it may never be necessary.
- sagarm 10mo agoI think you're right that it won't matter for most companies. But having been at a company with persistent DB performance issues with UUIDv4 keys as a contributing factor, it sucks.
- mrkeen 10mo agoIf you have too many UUIDs, throw more DBs at the problem. Hopefully you haven't tied yourself to any architectural decisions that would limit you to only using a single database.
- sgarland 11mo agoIME, when performance issues become obvious, the devs are in growth mode and have no desire / time to revisit PK choice. Integer PKs were seen as fine for years - decades, even - before the rise of UUIDs.