Because of its simplicity and its stability. And it’s absolutely capable of replacing many “traditional” RDBMs from a performance perspective or data size capability standpoint.
I’m not claiming that sqlite is capable of delivering high performance on par, the reason is that so many applications don’t need more performance that what sqlite is capable of.
For production setups, you usually want high-availability. So unless you use it on a network file system like EFS (which the SQLite author recommends against), SQLite is not an option.
But it just so happens that I’ve seen in the real world so many single instances of Oracle, PostgreSQL, Maria/MySQL, SQL Server etc. that I know in practice there is a big difference between what someone needs/wants and what someone gets.
A lot of that has also to do with the complexity of setting up HA instances of such databases. Also this is simpler with HA sqlite setups.
Not all production setups require >99.999% availability. There are many cases when it’s OK to use a VM with periodic snapshots/backups. In case of a HW failure (which doesn’t happen often) you can recover from a snapshot. An advantage is than an app with a DB in a file (no HA) requires almost no maintenance work.
12 comments
[ 2.5 ms ] story [ 40.4 ms ] threadhttps://sqlite.org/hctree/doc/hctree/doc/hctree/index.html
I’m not claiming that sqlite is capable of delivering high performance on par, the reason is that so many applications don’t need more performance that what sqlite is capable of.
[1] https://turso.tech/
But it just so happens that I’ve seen in the real world so many single instances of Oracle, PostgreSQL, Maria/MySQL, SQL Server etc. that I know in practice there is a big difference between what someone needs/wants and what someone gets.
A lot of that has also to do with the complexity of setting up HA instances of such databases. Also this is simpler with HA sqlite setups.