dqlite

Also there is dqlite[0]. I really do think that SQLite can go even farther than people think, but the exploration makes less and less sense the better and easier to run options like postgres become. That said, I'm glad projects like dqlite and rqlite exist. There are also previous threads discussing them but here's one[1]. [0]: https://github.com/CanonicalLtd/dqlite [1]: https://news.ycombinator.com/item?id=20836331

Interesting nugget about golang from their FAQ: https://github.com/canonical/dqlite/blob/master/doc/faq.md Why C? The first prototype implementation of dqlite was in Go, leveraging the hashicorp/raft implementation of the Raft algorithm. The project was later rewritten entirely in C because of performance problems due to the way Go interoperates with C: Go considers a function call into C that lasts more than ~20 microseconds as a blocking system call, in that case it will put the goroutine running that C call in waiting queue and resuming it will effectively cause a context switch, degrading performance (since there were a lot of them happening). See also this issue in the Go bug tracker. The added benefit of the rewrite in C is that it's now easy to embed dqlite into project written in effectively any language, since all major languages

https://github.com/canonical/dqlite/blob/master/doc/faq.md#a... http://man7.org/linux/man-pages/man2/io_submit.2.html

Based on the following header file, it would seem that they are using this unsupported module. https://github.com/canonical/dqlite/blob/master/src/vfs.h

Ahhhh thank you -- that information just got pushed into the FAQ -- I was thinking "surely they didn't just remove this information" but didn't look hard enough at all. Direct link: https://github.com/canonical/dqlite/blob/master/doc/faq.md#h...

> dqlite is/was WAL frame-based...maybe this isn't the case any more According to https://github.com/canonical/dqlite/blob/master/doc/faq.md this is still the case.

There's one more big distinction, rqlite's replication is command based [0] where as dqlite is/was WAL frame-based -- so basically one ships the command and the other ships WAL frames. This distinction means that non-deterministic commands (ex. `RANDOM()`) will work differently. It looks like dqlite's documentation has changed -- for some reason frames are no longer mentioned anywhere[2]. So maybe this isn't the case any more, but this was once the biggest differentiator for me. [0]: https://github.com/rqlite/rqlite/#limitations [1]: https://webcache.googleusercontent.com/search?q=cache:p1XBgh... [2]: https://github.com/canonical/dqlite/commit/35ea7cd56e93a36c5...

It has been around for 2 years and half, but we released v1.0.0 just yesterday. I added answers to your other questions to the FAQ: https://github.com/canonical/dqlite/blob/master/doc/faq.md#w... https://github.com/canonical/dqlite/blob/master/doc/faq.md#w... https://github.com/canonical/dqlite/blob/master/doc/faq.md#i...

From the FAQ[1] The main differences from rqlite are: - Embeddable in any language that can interoperate with C - Full support for transactions - No need for statements to be deterministic (e.g. you can use time()) - Frame-based replication instead of statement-based replication [1] https://github.com/canonical/dqlite/blob/master/doc/faq.md

I was reading through the docs and this FAQ is worth checking out: https://github.com/canonical/dqlite/blob/master/doc/faq.md In includes an answer about the difference with rqlite. To me reading the docs it seems like dqlite has been developed by the team who develops LXD at Canonical as LXD is listed as the biggest user of the project and it says on the authors github that he works at Canonical at/with LXD/LXC. Interesting project, good luck to the author/authors if you read this!

If someone wanted to do it, the lxc/lxd team has a distributed sqlite, so you could adapt that to k3s. Though I suppose that's not a good match for the stated purpose of k3s. https://github.com/lxc/lxd/blob/master/doc/database.md https://github.com/CanonicalLtd/dqlite