I dont get why you would want this. Most of sqlite's unique benefits come from its unique design choice of being in process. If you did queries over the wire you'd just get worst of both worlds.
I implemented once the MySQL network protocol (in TypeScript) to talk to a local SQLite DB. We used that for our CI environment, since our apps only did very vanilla SQL operations. It worked like a charm. So I can totally see some uses for such a beast -- but probably all of them are pre-production.
Postgres has foreign data wrappers which can kinda achieve this(see also: https://github.com/pgspider/sqlite_fdw ), but ive been surprised by how well sqlite is already supported by many tools : sometimes it comes for free as its used in testing - hooking up stuff like litestream can work really wel l too
FDWs still requires an instance of Postgres to be running. With implementing the Postgres wire protocol, you could theoretically use any Postgres driver to talk to a SQLite database with no client changes and no instance of Postgres
DuckDb supports reading/writing to a SQLite database, while using the improved DuckDB syntax. Sounds too good to be true, but I keep meaning to explore if there are any obvious gotchas.
But isn't this the point of being able to use both duckdb databases and sqlite databases from the duckdb runtime? You can mix and match read/write use-cases within the same duckdb db runtime?
Perform OLTP actions against sqlite db from within duckdb.
Perform OLAP actions against duckdb db from within duckdb.
Sometimes your OLTP content drives the OLAP query so read from both sqlite db and duckdb db at the same time.
