December 15, 2025
Big IDs, bigger drama
Avoid UUIDv4 Primary Keys
Database geeks roast random IDs; "Make it v7"
TLDR: A database expert says random IDs (UUIDv4) hurt performance, pushing developers toward time‑ordered UUIDv7 or plain numbers. Comments fire back: some say it’s Postgres‑only drama, others champion v7, and one hero just wants IDs you can double‑click—because usability pain beats theory.
The internet’s database crowd grabbed popcorn as Andrew Atkinson declared: avoid UUIDv4—those long, totally random ID codes—because they slow down inserts and lookups in Postgres. Translation: random IDs make your database shuffle harder, burning time and storage. Cue the comment brawl.
One camp cheered the warning, but mocked the scope: jwr shrugged, saying the advice is basically “in mice”—as in, only in Postgres. Others pushed a practical fix: use UUIDv7, a more orderly, time-flavored ID, with plugins today and official support promised in Postgres 18. benterix liked the diagnosis but rolled eyes at the author’s suggested integer “obfuscation,” calling it not production-ready. Meanwhile, fans of unique codes argued UUIDs are handy when multiple apps need to mint IDs without colliding—think many kitchens making the same dish without bumping into each other.
Then came the nitpicking: dotancohen questioned whether “random” just means “not sequential,” sparking a mini debate about what “order” even is. xandrius boiled it down to a one-liner: prefer v7, install plugin, done. And the best joke? waynenilsen doesn’t care about performance—he just hates that you can’t double‑click those monster IDs to select them. Tech pain is real. The vibe: for single-app databases, keep it simple; if you must go fancy, make it v7 and move on.
Key Points
- •The author advises against using UUIDv4 as primary keys in PostgreSQL due to observed poor performance and excessive I/O.
- •UUIDv4’s randomness degrades index insert performance and hampers efficient single-item and range retrievals.
- •gen_random_uuid() has made UUIDv4 easy to generate since PostgreSQL 13 (2020), contributing to its adoption despite drawbacks.
- •UUIDs can be justified when client-side or multi-service ID generation is required to avoid collisions; integer sequences cannot guarantee this across systems.
- •UUIDv7 is slated for inclusion in PostgreSQL 18 (Fall 2025), offering a future alternative after being pulled from PostgreSQL 17.