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, client-server 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'm glad this covers UUIDv7. Unless you need cryptographically-random, unpredictable row IDs, using UUIDv7 helps a lot with the performance by making the keys ordered at least.
awesome!
but seriously who uses UUID as their primary keys? what's wrong with plain old INT. it's more predictable you can look at the integer primary key and tell which records created when relative to each other. also you can easily remember them. unlike UUID.
This goes to show that using uuid4 is not a good thing for db tables, but that is what uuid7 was designed for. Also using ROWID or autonumber or whatever built in system the database is using is the best bet. Only use uuid7 if you need distributed inserts and you want the clients to be able to generate their own keys.
all 21 comments