[free-ekanayaka]

Hello, author of dqlite here.

Things are still in flux, but yes, I plan to publish benchmarks before making a 1.0 release, as well as improving documentations and introduce some more abstractions to make it easier to use.

The reason it might be slower is some cases is that RQlite replicates statements and dqlite replicates WAL frames (where "frames" roughly means "disk pages"), which are typically bigger.

I didn't run benchmarks against RQlite yet, but I'd expect performance differences to be negligible for most use cases.

[hardwaresofton]

Hey thanks for putting this out there, it's a pretty cool project.

I see what you meant by it being slower, but that's only replication speed right? maybe that should be pointed out in the documentation when you find time to update it.

Does it seem like the replication patch is going to land in Sqlite? I sure would like it to...

[free-ekanayaka]

"slower" means this:

when you perform a SQLite write, SQLite writes a new page on disk to the its write-ahead log. dqlite needs to replicate that page write across all nodes. A page is typically 4kb, so when you do a write on the leader node you need to transfer 4kb across the wire to all other follower nodes and wait for a quorum of them to come back and say "I got it" (which includes writing the page to disk). On the contrary rqlite just needs to transfer and store the SQL text, which is typically less than 4kb.

In practice it's still pretty performant, but I'll publish benchmarks later on.

I plan to submit the patch to SQLite upstream too, yes.