I'm surprised they didn't spend more time talking about HCTree branch.

https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html

That branch seems to be a prototype.

We need more sqlite on the servers. Much more.

Why?

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.

Systems are simpler, and not requiring a network connection also makes them more performant.

You can /should use sockets with ppstgresql, and even your backend (app server).

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.

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.

If HA is what you need, there are solutions.

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.

In most cases, primary/failover is more than enough for high availability - and things like LiteFS are able to provide that for SQLite.

Related: Turbo [1] helps dealing with SQLite replication in a different way.

[1] https://turso.tech/