[Edit] The only thing that'd be different for Rust and/or C is the avoidance of "stop-the-world" GC pauses, which affect Java more, but are still present in Golang.
dqlite has 2 other advantages over rqlite: it supports transactions, and more importantly (IMHO), it works with Go's native sql.DB handler.
Yeah, I need to get around to creating a Go sql.DB layer. Been too busy adding to the database itself. :-) Soon!
Please do! That was the deal breaker when I was trying to migrate an internal project to SQLite/rqlite (couldn't slap an ORM on it).
Have you used this? Is it good? Having a distributed database seems like a great thing, but it kind of rubs me the wrong way that that database is SQLite; I associate it more with lightweight/in-process stuff, which is the opposite of distributed.
Sure, but rqlite tries to give you the best of both worlds -- a distributed database that is also lightweight and super-easy to run.
I came here to mention rqlite too. It's awesome, and non-voting nodes let you replicate out to many, many nodes w/o much performance issues.
Cheers, glad you like it -- great to hear.
rqlite author here, happy to answer any questions about it. It seems some folks have questions about its design, and the design of systems that combine SQLite and Raft in general. Checking out the rqlite design docs might be helpful: