Sure, if all data is in a single DB. But in the real world you’ve generally got some/all of: - 1 or more data warehouses - Other services storing said data (e

Sure, if all data is in a single DB. But in the real world you’ve generally got some/all of: - 1 or more data warehouses - Other services storing said data (e.g. the user id will live in many databases in a service oriented architecture) - External API integrators who have their own data stores totally out of your control that also have copies of parts of your data - Job queues. It’s common to have jobs scheduled for the future on some other system (Redis, etc.) that say “do X for user with id Y in Z days”. If the “id” changes these fail - Caches. Say I cache data by user email instead of a surrogate key, user changes their email, and another user signs up with the old email. Cache hits for the wrong user! - etc. Changing the primary key becomes an absolute nightmare project once data lives in multiple places like this, and in my experience it mostly does. Having truly stable identity for your entities just solves so many future problems, and it’s SO easy to do. In almost all cases, natural PKs are really all downside, virtually zero upside, except slightly less storage.