Coupling a file format to SQLite smells wrong.
SQLite is good, but it is also fairly unique in this space. Why? Because it’s hard to replicate everything it does, because it does a lot.
But… for this case, do we need it do a lot? No, not really. We don’t need the full SQL standard, a query optimiser, etc etc for basic (+ safe) transaction semantics and the ability to store data in a basic table structure.
Perhaps there is a better file format we can use, but it would be better if it was decoupled from SQLite.
- Why not? https://www.sqlite.org/appfileformat.html
- Its size is less than a megabyte: https://sqlite.org/footprint.html
- 750KB if all features are enabled: https://www.sqlite.org/about.html
- Looks like fair amount of functionality can be left out when compiling sqlite and with options to influence/strip down query planner: https://www.sqlite.org/compile.html
- And "SQLite does not compete with client/server databases. SQLite competes with fopen()": https://www.sqlite.org/whentouse.html
In the end, you don't need a database, but a library that gives you database API and behavior.
The complaint is not “it isn’t good” but rather “it is not replaceable”. Since SQLite is so powerful, once you specify it as a format, you are stuck with SQLite forever.
Which is also "not a big issue", since it's a recommended Library of Congress storage format, and supported long term:
It is somewhat of a problem: the development team is very small, they don't take outside contributions (so nobody outside the core team really builds up expertise over time), and the vast majority of tests are proprietary. I hope they have a contingency plan just in case (some sort of a dead man's switch that publishes the test suite under a permissible license) as it would probably be quite difficult for others to maintain the same quality without those tests, or re-implement them in a reasonable time frame.