rqlite[1] could basically do this, if you use read-only nodes[2]. But it's not quite a drop-in replacement for SQLite at the write-side. But from point of view of a clients at the edge, they see a SQLite database being updated which they can directly read[3].
That said, it may not be practical to have hundreds of read-only nodes, but for moderate-size needs, should work fine.
(author here) I had looked at both Rqlite and the different commercial versions of this, but I didn't pursue them as they all seemed to require running an additional service on the host machines.
Yes, that is right, it would require a new service running on the host machines.
That said, I do think it depends on what you consider important, and what your experience has been in the past. I used to value simplicity above all, so reducing the number of moving pieces was important to my designs. For the purpose of this discussion let's count a service as a single moving piece.
But over time I've decided that I also value reliability. Operators don't necessarily want simplicity. What they want is reliability and ease-of-use. Simplicity sometimes helps you get there, but not always.
So, yes, rqlite means another service. But I put a lot of emphasis on reliability when it comes to rqlite, and ease-of-operation. Because often when folks want something "simple" what they really want is "something that just works, works really well, and which I don't have to think about". SQLite certainly meets that requirement, that is true.
rqlite is a great project! Sometimes I have been wondering, how hard would it be to embed it into web server process, like nginx or apache, as a module.
That said, it may not be practical to have hundreds of read-only nodes, but for moderate-size needs, should work fine.
Disclaimer: I'm the creator of rqlite.
[1] https://rqlite.io/
[2] https://rqlite.io/docs/clustering/read-only-nodes/
[3] https://rqlite.io/docs/guides/direct-access/