But then why do you need to write to the DB remotely?
It seems like the inflection point moving from "single-local-application" to "writing-to-remote-db" would be an appropriate point to switch from a single file DB to a larger RDBMS.
I can think of a few scenarios where it could make sense, like a shared small DB on a LAN that doesn't need a full fledged "server", but a primary/secondary relationship makes sense. But those are pretty few... and n>1.
Obviously someone wrote this because they felt a need for it, but I'm struggling to see the use-case. Maybe it's good for CI/or unit testing?
The use case mentioned for http is: you have edge services that need to be able to query a db and http might be the only open way to communicate. Exactly why you run on the edge or use sqlite is actually off topic. I mean I run User Mode Linux in production because it was just easier than the alternative when we first developed it.
I self host a lot of stuff at home. I don't need a large RDBMS. A lot of software is written for Postgres and I don't bother running it as I don't want to manage it. I'm really interested in this if I can start using those apps now, without spinning up postgresql.
It seems like the inflection point moving from "single-local-application" to "writing-to-remote-db" would be an appropriate point to switch from a single file DB to a larger RDBMS.
I can think of a few scenarios where it could make sense, like a shared small DB on a LAN that doesn't need a full fledged "server", but a primary/secondary relationship makes sense. But those are pretty few... and n>1.
Obviously someone wrote this because they felt a need for it, but I'm struggling to see the use-case. Maybe it's good for CI/or unit testing?