30
The perils of UUID primary keys in SQLite
(andersmurphy.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Jun 2026
30 points (96.9% liked)
Programming
27173 readers
447 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
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 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.