Serial integers always work better than any uuid as PKs, but the thing with uuid4 is that it disrupts any kind of index or physical ordering you decide to put on your data.
Uuids are really for external communication, not in-system organization.
Serial index forces a synchronisation point on every entity that can create records. If this is only ever a single database that’s fine but plenty of apps can’t scale this way.
Anything non-k-sortable in a B[+,-]tree will cause a ton of page splits. This is a more noticeable performance impact in RDBMS with a clustered index (MySQL's InnoDB, MS SQL Server) [0], but it also impacts Postgres [1] in multiple [2] ways.
marcosdumay|2 years ago
Uuids are really for external communication, not in-system organization.
dalyons|2 years ago
ildjarn|2 years ago
sgarland|2 years ago
[0]: https://www.percona.com/blog/uuids-are-popular-but-bad-for-p...
[1]: https://www.cybertec-postgresql.com/en/unexpected-downsides-...
[2]: https://www.2ndquadrant.com/en/blog/on-the-impact-of-full-pa...