It’s weird their main reason is performance, but then proceed to benchmark SQLite. Who’s inserting 10s of millions of records per minute on sqlite?
Even in production DBMSs, I’d wager that there are plenty of other things that dominate performance before you even get near your choice of a primary key, so it probably doesn’t matter until you get a large enough throughput in your database.
But that’s the thing with benchmarks, you run them because making assumptions about performance based on guesswork often fails. SQLite is very much architecturally unique for being a daemon-less database that doesn’t concern itself with concurrent writes.
Is UUID as pk slower than int or bigints? Probably - you’re storing 4x more data than a 32-bit integer. Does it matter? Probably not.
It’s weird their main reason is performance, but then proceed to benchmark SQLite. Who’s inserting 10s of millions of records per minute on sqlite?
Even in production DBMSs, I’d wager that there are plenty of other things that dominate performance before you even get near your choice of a primary key, so it probably doesn’t matter until you get a large enough throughput in your database.
I would say their findings would be pretty consistent no matter which DBMS you use.
But that’s the thing with benchmarks, you run them because making assumptions about performance based on guesswork often fails. SQLite is very much architecturally unique for being a daemon-less database that doesn’t concern itself with concurrent writes.
Is UUID as pk slower than int or bigints? Probably - you’re storing 4x more data than a 32-bit integer. Does it matter? Probably not.
UUID could be slower for SQLite. If you have a SEQUENCE and millions of concurrent writes you have other problems.