[AtNightWeCode]

The counter argument I would say is that having all these integer ids comes with many problems. You can't make em public cause they leak info. They are not unique across environments. Meaning you have to spin up a lot of bs envs to just run it. But retros are for complaining about test envs, right?

Uuid4 are only 224bits is a bs argument. Such a made up problem.

But a fair point is that one should use a sequential uuid to avoid fragmentation. One that has a time part.

[kgeist]

Some additional cases we encounter quite often where UUIDs help:

- A client used to run our app on-premises and now wants to migrate to the cloud.

- Support engineers want to clone a client’s account into the dev environment to debug issues without corrupting client data.

- A client wants to migrate their account to a different region (from US to EU).

Merging data using UUIDs is very easy because ID collisions are practically impossible. With integer IDs, we'd need complex and error-prone ID-rewriting scripts. UUIDs are extremely useful even when the tables are small, contrary to what the article suggests.

[andatki]

If merging or moving data between environments is a regular occurrence, I agree it would be best to have non-colliding primary keys. I have done an environment move (new DB in different AWS region) with integers and sequences for maybe a 100 table DB and it’s do-able but a high cost task. At that company we also had the demo/customer preview environment concept where we needed to keep the data but move it.