The counterpoint is "You Don't Need to Micro-Optimise Your PK Type". UUIDs offer by far the best developer UX. They're first class objects for most of your tec

The counterpoint is "You Don't Need to Micro-Optimise Your PK Type". UUIDs offer by far the best developer UX. They're first class objects for most of your tech stack, and they eliminate or massively simplify a lot of potential backend issues, from idempotency to merges to sharding. The main downsides are two: - They're not human friendly. This is a good thing. Surrogate keys should never be exposed to the human user, because what is a 1:1 mapping today may not be 1:1 any longer tomorrow. If you need to let the user input a unique object reference manually, you're free to design that reference with human UX in mind. Maybe it's a set of dictionary words, maybe it's a code with an expiration date, maybe it's the same code but referring to different versions of the object depending on the user. The only people who may need to copy/paste UUIDs manually are database admins, and they will thank you so much more for never bothering them with fixing a pkey clash or an accidental join on the wrong key. - They are less performant than sequential integers. For 99% of projects this is not going to be an actual issue. Once you _do_ find that your queries are being slowed down by the size of primary keys specifically, you have my absolute blessing to add an integer sequence column and make that the primary key.