Why You Should Avoid UUIDs
I’m a bit of a low key UUID buff, and not just the RFC 4122 variety. I use the term loosely, as a category for unique identifiers generated by stateless, distributed algorithms. I even wrote a Go library called ksuid, a stateless and lexicographically sortable mash up of Snowflake IDs and RFC 4122 UUIDs.
I think developers overuse UUIDs. In short, if you don’t need to generate unique identifiers in a distributed, stateless fashion, you don’t need UUIDs. They will only make things worse.
If you’re using a relational database as your application’s source of truth, it has some variant of serial or auto-increment columns. Use those, you don’t need UUIDs. They will bloat your tables and slow down your queries. Another one: non-sequential identifiers like UUIDs further destabilize keyset pagination. And for what?
Many times I’ve witnessed UUIDs stored as strings, because storing them in binary format or in a native UUID type requires a few extra tiny incantations. Storing a UUID as a string turns 16-bytes into at least 36 bytes. Think about the extra cycles, cache misses, and disk reads. If UUIDs were avoided in the first place, they’d be processor-register-sized integers instead. All downside, no upside.
What about the chance that in the future the data set grows so large that it needs to be distributed? It probably won’t. If that does come up, there are options. Here’s one: use UUIDs for new data, past data can keep the existing identifiers. It’s even safe to interpret the existing integer identifiers as UUIDs!
My rule of thumb: first try to use the native unique identifier generation or convention of the chosen data storage technology, and if it doesn’t work, or it doesn’t make sense, or if it ruins performance, then reach for UUIDs.
I’m not saying that we should all rush out to extricate our software using UUIDs without a true need. Not at all. But using them only when necessary is one of those rare choices that doesn’t involve a trade-off. It is trivial to choose correctly up front and completely impractical to change down the line.
