rqlite author here.

There are a couple of statements on that page I disagree with.

"mvsqlite is a distributed database, while dqlite and rqlite are replicated databases"

I disagree with this statement, and consider its definition of "distributed system" to be incorrect. rqlite[1] is a distributed database. A "distributed system" is simply a system that splits a problem over multiple machines, solving it in a way that is better, more efficient, possible etc than a single machine. rqlite uses distribution to provide fault-tolerance and high-availability. It uses distributed systems technology i.e. Raft, to make rqlite appear up-and-running, even in the face of node failures. That it replicates a full copy of the SQLite database to every node is correct, but that doesn't mean it's not a distributed system. Is Consul a distributed key-value store? etcd? By the definition quoted on that page they are not, but no one would actually agree with that.

rqlite is not just about replicating a SQLite database. I understand what the page is trying to say, but the point is that rqlite is distributed, just for fault tolerance and high-availability.[2]

"(+): mvsqlite runs on a production-grade distributed key-value store, FoundationDB, instead of implementing its own consensus subsystem."

rqlite doesn't implement its own consensus system either. It uses the same Raft consensus code that powers Hashicorp Consul. I don't see how this is any different, in principle, than using Foundation DB's consensus system.

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

[2] https://github.com/rqlite/rqlite/blob/master/DOC/FAQ.md#rqli...

Hi otoolep, thanks for the corrections! Actually I've just made a few changes to the wiki page before this comment :)

rqlite's readme seems to indicate that it uses Consul only for service discovery, and runs Raft internally?

I think the most important difference here is rqlite runs its "data plane" on a single consensus group/state machine while mvsqlite relies on FDB's distributed transaction system (well at the bottom there's a Paxos but it is only used for metadata coordination). Both approaches have advantages and disadvantages though.

Correct. What I meant by the reference to Consul is that rqlite uses the Raft implementation at its center and repurposes for use by rqlite.

I can make that clearer.

And good luck with your project, welcome to the distributed SQLite space. :-)

Looks like in their view "fully distributed" == "write scalability", which is, of course, very limited view.

Exactly. Providing write-scalability is big deal, don't get me wrong, and this project looks interesting. The biggest misconception folks have about rqlite is that it increases SQLite write performance, when it's about providing fault-tolerance and reliability.

So projects like mvsqlite are solving a real need. I just disagree with some of its definitions.

But is it Byzantine Fault Tolerant? From what I understand, RAFT is not. Paxos-based consensus can be made to be.

That's nobody's business but the Turks'.

The approach is different -- both rqlite and dqlite sit "on top" of SQLite and are much more like replication and coordination layers.

IIRC rqlite replicates commands, dqlite replicates WAL frames, mvsqlite intercepts file system calls because it's a VFS implementation [0].

[0]: https://www.sqlite.org/vfs.html