36
The perils of UUID primary keys in SQLite
(andersmurphy.com)
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
Follow the wormhole through a path of communities !webdev@programming.dev
Using integer primary keys often creates race conditions (that result in collisions) when you have multiple database shards, so UUIDs have become the standard. (2 different webservers can create a record in 2 different database that then sync with eachother in the background). Using UUIDs for SQLite is less common though as SQLite is mostly used for small or local applications, but developers are used to UUIDs now and even consider them the standard for primary keys now so you do see them in SQLite databases. (Oh and there's some SQLite compatible sharding servers too)
Can't you just reserve X bits of the primary key to store a shard ID?
You would be inventing some style of UUID. Include a timestamp in front, so that it is sortable and you have Snowflake.
If you are owning every little part of the design in every nuance, sure. But how do you configure this in mysqll, postgres, etc etc. does your favorite framework support this easily.
wow, I didn't know we can have multiple databases for a single app/website. I assumed it wasn't possible when I learned about k8s and the teacher said there will always be one database while you can replicate your frontend/backend pods
Both setups are possible.