I broadly agree, however running a cache/networking layer is difficult, and is handled well by other open sourced implementations.

If someone already wrote that networking layer, why would I want to do it again? And run into all of the bugs that they already discovered and solved?

Agreed, although we are having this discussion now exactly because those same problems are starting to get solved for SQLite in an open and polished way, so it is no longer a case of needing that second networking layer to integrate with such solutions.

Do people build their own networking layers above SQLite (besides for fun)? If you’re doing that, then you need to build some kind of replication story. At that point it makes sense to just use PG or MySQL

Unquestionably. Web apps and the like which are little more than networking frontends to a database are probably the most common type of software written these days.

Ah, we’re talking about different things. I took “network layer” to mean something like the ability to connect directly to the database over the network, not through some shim application.

Meaning something like rqlite[1]? The age of fat desktop clients all connecting back to the central SQL server is long behind us, so yeah there is probably little reason beyond fun for something like that these days, but where there is fun!

[1] https://github.com/rqlite/rqlite

Ha! PostgreSQL still needs some kind of replication story! ;)

(PS. Mostly just pointing out that replication is still a bit awkward.)

Most apps nowadays are HTTP APIs on top of a database, which means we have one networking layer – the HTTP API – on top of another networking layer – the database protocol. The idea behind using SQLite is to just skip the latter, which is simplifying the stack significantly and reducing the database latency, which is making things like 1+n not a problem anymore.

With a tool like LiteFS, it is now possible to get replication done by a sidecar process: https://fly.io/docs/litefs/

It's because people are using super slow languages which incur lots of overhead in running the queries and formatting the results into human readable form. As such they need many more machines to run these webapp machines than they do to run the database itself.

And stored procedured, debugging, JIT compilation, extension in multiple languages, ....