Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
First of all, great idea, and a brilliant and highly laudable effort!
Favorited!
One minor caveat ("Here be Dragons") I have (with respect to my own future adoption/production use), however:
https://github.com/rqlite/rqlite/blob/master/DOC/FAQ.md
>"Does rqlite support transactions?
It supports a form of transactions. You can wrap a bulk update in a transaction such that all the statements in the bulk request will succeed, or none of them will. However the behaviour or rqlite is undefined if you send explicit BEGIN, COMMIT, or ROLLBACK statements. This is not because they won't work -- they will -- but if your node (or cluster) fails while a transaction is in progress, the system may be left in a hard-to-use state. So until rqlite can offer strict guarantees about its behaviour if it fails during a transaction, using BEGIN, COMMIT, and ROLLBACK is officially unsupported. Unfortunately this does mean that rqlite may not be suitable for some applications."
PDS: Distributed transactions are extremely difficult to get exactly right -- so I'm not trying to criticize all of the hard work and effort that everyone has put into this (again, it's a great idea, and I think it has a terrific future).
But Distributed Transactions -- are what differentiate something like rsqlite from say, something like CockroachDB (https://www.cockroachlabs.com/docs/stable/architecture/life-...).
Of course, CockroachDB is a pay-for product with an actual company with many years of experience backing it, whereas rqlite, as far as I can intuit, at this point in time, appears to be a volunteer effort.
Still, I think that rqlite despite this -- has a glorious and wonderful future!
Again, a brilliant and laudable effort, suitable for many use cases presently, and I can't wait to see what the future holds for this Open Source project!
Maybe in the future some code-ninja will step up to the plate and add fully distributed transactions!
Until then, it looks like a great idea coupled with a great software engineering effort!
As I said, "Favorited!".
I just open-sourced a streaming replication tool for SQLite called Litestream that does physical replication (raw pages) instead of logical replication (SQL commands). Each approach has its pros and cons. Physical replication logs tend to be larger than logical logs but I agree that you avoid a lot of issues if you do physical replication.
https://github.com/benbjohnson/litestream
https://github.com/adsharma/raft
Bug reports welcome
Bob: /status
Etc
https://github.com/adsharma/zre_raft
The initial issue seems to be saying that it's because they need to have etcd anyway, so consolidating on that removes a dependency. Which fits their simplicity goal.
https://github.com/k3s-io/k3s/issues/845