Hacker News Reader

Comment by api | Hacker News Reader

SQLite plus a fast Raft replication and consensus implementation is the next Postgres. Change my mind.

This exists already with rqlite: https://github.com/rqlite/rqlite

As much as I love the idea, Raft is not a silver bullet and can break in strange and inconspicuous ways that may be difficult to fix. It can also lead to subtle inconsistencies in the data depending on what data you are putting in it. Overall it may be good in some situations, but I doubt it will dislodge Postgres in any meaningful way.

What inconsistencies do you mean, precisely? I think you need to provide a clear example of what you mean, to understand what you're getting at.

In my experience, any inconsistencies would be due to misuse of Raft, not something intrinsic to Raft itself.

Thanks for chiming in, Philip! I’m a big fan of your work.

I was referring to the issues around determinism in queries. These are easy enough to catch if you’re aware of them, but it pushes more onus onto the application layer / devs (not that it’s necessarily a bad thing, just a trade-off).

Wouldn't this be true of any form of replication, including whatever Postgres uses? Or is the proof of correctness for Raft weaker than some other class of consensus?

Edit: from rqlite's FAQ

> Raft is a Consistency-Partition (CP) protocol. This means that if a rqlite cluster is partitioned, only the side of the cluster that contains a majority of the nodes will be available.

Disconcertingly, this sounds like they assume that only one side of a partition can contain a majority of nodes. This isn't true if the partition is partial, eg A<-->B, B<-->C, A<-/->C.

rqlite creator here.

rqlite (and Raft) doesn't assume this. All it states is that for the cluster to make progress i.e. apply a change in a consistent manner, at least a quorum of nodes must be online and in contact with the Leader (which is one of the online nodes). Every node in a rqlite cluster knows what size the cluster is and therefore requires that (N/2)+1 nodes acknowledge the change before that change is committed. The Leader node performs this coordination.

The scenario you outlined above is obviously possible. But in that event the cluster is down -- the Leader (let's say it's node A) cannot contact a quorum of nodes. No changes can be made to it.

Gotcha, that makes sense. I look forward to digging into the code myself :).

rqlite is nice but it's got limitations that made me look elsewhere. https://dqlite.io/ does it in C and allows for transactions and can be used for the Go sql.DB object.

https://www.sqlite.org/whentouse.html

See: Situations Where A Client/Server RDBMS May Work Better

https://github.com/rqlite/rqlite

https://github.com/canonical/dqlite

Multi-writer concurrency with sqlite is a giant pain in the ass.

There are, nonetheless, lots of situations where I would have reached for pg automatically a few years ago where I now stop and think about which of the two is going to fit my use case better.

The comment you're replying to is saying rather more than that, and I don't endorse it, but the shift in the possibility space is still both fascinating and impressive.

(also I love sqlite's tendency to use pg as a syntax template, it seems like an example of two projects with significantly different goals playing to each others' strengths in a beautifully positive sum game fashion)

The writers need to be serialized but it's not that big a pain.

Multiple reader single writer out performs Postgres in my testing, by a large margin.

I don't know if SQLite + Raft is going to be the next Postgres, but it's certainly an interesting solution for a variety of use cases where you don't need your data _partitioned_ on multiple machines (but still want it to be replicated for availability and fault tolerance).

As others point out in this thread, there's already rqlite for Go, sqlite for C, and now we've open sourced our work on bringing SQLite and Raft to Rust: https://glaubercosta-11125.medium.com/winds-of-change-in-web...

Adding Raft and replication will make your database more available but strictly slower and not any more concurrent. If SQLite is not good enough for you now it probably wouldn't be any good for you then.

SQLite is not a high throughput database. Trying to work around this with cool tech is not likely to make it better than a boring solution, like using a high throughput database in the first place.

My SQLite usages are able to saturate my NVMe storage devices in many test cases. Not sure what exact criteria you are using for "high throughput" here. Perhaps you are not familiar with the additional WAL journal mode or synchronization flags?

SQLite3 is not a high-write-concurrency database, but not a high-throughput DB is less clear, and it's not at all clear that it can't be hacked on to go faster.

If you take a sharding approach to concurrency, you might just be happy with no write concurrency: one process/thread per-CPU / storage slice, and fix everything else upstairs. It's not a crazy approach, and it might be the approach many would take if they could start from scratch. In fact, it's the approach Spanner takes, for example.

Reply on news.ycombinator.com