Yes I do have practical experience to share, I wrote a blog post on rqlite and FTS5: https://philipotoole.com/building-a-highly-available-search-...
Will it allow you to reach the same scale in terms of data set size that Elasticsearch supports? Almost certainly no, but it might be enough depending on your use case.
otoolep•4w ago
https://rqlite.io
sgarland•3w ago
I recently had a potential use case for this, but it required somewhere around 600 writes/sec at a minimum, and it wasn’t clear what the ceiling was for rqlite without sacrificing durability guarantees.
Terrific bit of software, BTW!
otoolep•3w ago
- https://www.philipotoole.com/2021-rqlite-cmu-tech-talk - see slide 33.
- There is also a recording that goes with the talk: https://www.youtube.com/watch?v=JLlIAWjvHxM
You can also read about Performance in the docs at: https://rqlite.io/docs/guides/performance/
An important thing to note: this testing was done 4+ years ago, on moderately-powerful hardware for the time. With higher-end, more modern hardware you may get even better results.
sgarland•3w ago
I suppose I could try my own benchmark out tbf. I’m curious to see what it can do on today’s hardware. I would think it’s mostly network-bound for Raft consensus, though the 10x ping time increase you demonstrated without an appreciable drop in writes suggests it’s more complex than that.
otoolep•3w ago
I did introduce Queued Writes[1] since that talk, allowing you to trade off performance versus immediate durability. It may interest you -- network is much less of a factor then, and you should get a 10-100x increase in throughput.
[1] https://rqlite.io/docs/api/queued-writes/
sgarland•3w ago
otoolep•3w ago
Otherwise, if you try with more modern networks and disks, let me know what you see.