Blog post author here (I did not post the link above to HN). I also wrote a short follow-up blog post at https://philipotoole.com/proving-to-fable-i-maintain-the-rep...
HN user
otoolep
Software Engineer based in Pittsburgh, PA. Engineering Manager at Google, building large-scale data systems. Creator of rqlite[1], the lightweight, distributed database built on SQLite.
https://www.philipotoole.com
[1] https://www.rqlite.io
You can learn about some known use cases here: https://rqlite.io/docs/features/#common-use-cases
One application that comes up over and over again -- wanting relational modeling, along with HA, but with low operational costs. People sometimes start with Postgres, then need to set up HA, and find it's a lot of work. They realize that their data set requirements are not huge, don't need fancy features, so start to think Postgres is overkill. That's what Replicated found.
I grew up in Ireland, moved to the USA as an adult. European government is clearly Hobbes in model, the US Lockean.
In Europe the individual has almost no legal reason to use force, and force by individuals is considered illegitimate. The "Sovereign" has all the coercive power in European states. In the US, however, a certain amount of legitimate force explicitly remains with the individual i.e. the 2nd amendment. (I am not making a value judgement here).
Of course, Europe has government with the consent of the governed, so is Lockean in that sense. But the balance of force between the "Sovereign" and the people in Europe is all Hobbes. You only notice it when you move to the US and compare it to Europe.
Europe had centuries of religious and civil war. It's not surprising Hobbes won out.
rqlite creator here, happy to answer any questions.
As for reliability - it's a fault-tolerant, highly available system. Reliability is the reason it exists. :-) If you're asking about quality and test coverage, you might like to check out these resources:
- https://rqlite.io/docs/design/
First of all, does anyone believe that highly scrutinized and bureaucratic functions are general high quality services?
This is the only part of your response that doesn't quite sit right with me. There could be many "highly scrutinized and bureaucratic functions" out there that are working very well, you just don't notice because they work so well. There could be a selection-effect here.
Quality is a big deal for me[1]. But I think you're defining "quality" too narrowly in this context. "Quality" could also mean "allows everyone, at scale, reliably, to do what they need to do." The US Tax Filing system (and its associated software) meets that goal.
[1] https://philipotoole.com/always-thinking-of-the-next-guy/
Blog post author here, thanks for your thoughtful comment. You raise some interesting things to think about.
OK, well, you could try client-side batching too, if you can. That will also improve performance substantially.
Otherwise, if you try with more modern networks and disks, let me know what you see.
Yes, fast networks matter.
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.
rqlite creator here.
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.
rqlite creator here. I have performed a fair amount of performance testing, some of which I outlined in a talk to the CMU Database Group a few years ago. Details:
- 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.
rqlite[1] creator here, happy to answer any questions.
rqlite creator here, happy to answer any questions.
rqlite[1] creator here.
Nit: dqlite is a library, it is not a network-exposed database like rqlite is. Sure, it requires connecting to other nodes over the network, but local access is via in-process. In contrast one connects with rqlite over the network - HTTP specifically.
rqlite[1] creator here. Thanks for the shout-out in your blog post.
rqlite[1] author here. Just to be clear, rqlite is not SQLite but rewritten in Go. rqlite uses the vanilla C code, and calls it from Go[2]. I consider that an important advantage over other approaches -- rqlite gets all the benefits of rock-solid[3] SQLite. As result there are no questions about the quality of the database engine.
There is a new continuum. "Team" is just a convenient word to emphasize that "Tools" are moving significantly in the "Teams" direction.
Exactly.
Post author here. Few things.
You are right that when someone (a human) submits a PR it didn't cost me anything (short of my time to review it). But those folks are not a team, not someone I could rely on or direct. Open-source projects -- successful ones -- often turn into a company, and then hire a dev team. We all know this.
I have no plans to commercialize rqlite, and I certainly couldn't afford a team of human developers. But I've got Copilot (and Gemini when I use it) now. So, in a sense, I now do have a team. And it's allowed me to fix bugs and add small features I wouldn't have bothered to in the past. It's definitely faster (20 mins to fire up my computer, write the code, push the PR vs. 5 mins to create the GitHub issue, assign to Copilot, review, and merge).
Case in point: I'm currently adding change-data-capture to rqlite. Development is going faster, but it's also more erratic because I'm reviewing more, and coding less. It reminds me of when I've been a TL of a software team.
I wonder the same thing myself, wouldn't surprise me if it's heavily subsidized. So much compute being given away for free.
Also, I don't value Copilot at $41.73. What actually happens is that GitHub charges me $41.73. I value it at way more. The consumer surplus here is substantial, IMHO.
Blog post author here.
From my perspective I didn't have a development team before. I have one now. I guess I am a member of that team now. But I hadn't thought of it like that -- another strange dimension to working Copilot (and its ilk).
rqlite creator here -- it's on my list to examine, not clear to me if it would add much beyond what is offered today. But it might.
rqlite creator here.
What you're describing sounds like "none", but adding the "limit read staleness" requirement. That is described in the docs.
https://rqlite.io/docs/api/read-consistency/#limiting-read-s...
rqlite[1] creator here, happy to answer any questions.
If you're interested in writing Raft-backed databases you might be interested in my talk at GopherCon 2023. It walks through doing exactly that, step by step: https://www.youtube.com/watch?v=8XbxQ1Epi5w
Related, but not exactly the same: https://blog.gopheracademy.com/advent-2014/case-against-3pl/
Cheers!
Yeah, the client libraries[1] need work. It's been difficult to keep them in good shape when there is so much to do on the core database itself. Any community input very much appreciated for the client libraries!
The first test of a class of tests is the hardest, but it's almost always worth adding.
Agreed, this has been my experience too.
I actually touched on this topic somewhat in a recent talk at GopherCon: https://youtu.be/8XbxQ1Epi5w?t=2223
The section of the talk at the timestamp above is titled "Should I use Raft"?