rqlite author here. https://github.com/rqlite/rqlite/ https://github.com/rqlite/rqlite/ Yes, there is no reason why that wouldn't work. rqlite supports on-disk

rqlite author here. https://github.com/rqlite/rqlite/ https://github.com/rqlite/rqlite/ Yes, there is no reason why that wouldn't work. rqlite supports on-disk mode so you could run litestream alongside an rqlite node and backup the underlying SQLite database to your favourite cloud provider using litestream. The only downside is that rqlite performance is very sensitive to the number of writes to disk, and that's why rqlite uses an in-memory SQLite database by default, and lets the Raft log persist to disk. In exchange you can be sure that your writes are persisted to disk when the API acks your request. Perhaps if rqlite used a RAM-based filesystem for everything, and you combined it with litestream you could get much higher-performance from rqlite, with backup (with only a tiny window for data loss) if you use litestream. It's not entirely trivial, however, due the difference in data consistency models. For example, which SQLite database should be updated if the Leader in the cluster changes? It gets complicated. Ben has written a great program here. I wish I had his ideas! It's got me thinking. :-)