Release 8.0 is out now and brings substantial advancements to its handling of large data sets. It also adds many new features, and brings improvements in simplicity and operation — all the while maintaining rqlite’s focus on robustness and quality.
I’ve been developing rqlite since 2014 and its design and implementation has evolved substantially during that time — and the design docs tell the story of what worked, and what didn’t. So what can we learn about distributed database design, from watching rqlite change over the years?
rqlite is a lightweight, open-source, distributed relational database written in Go, which uses SQLite as its storage engine and Raft for distributed consensus. Release 7.0 is out now and introduces the first wave of new Node Discovery and Automatic Clustering features.
rqlite is a lightweight, open-source, distributed relational database written in Go, which uses SQLite as its storage engine. v6.0.0 is out now and makes clustering more robust. It also lays the foundation for more important features.
There is a popular image out there, among the general public, that small startups — particularly small software startups — are a hotbed of technical innovation, constantly creating new technology. But is it true?
If you work in the logging, monitoring — or even Observability — space long enough, you eventually end up on team that tries to build a system that handles both logs and time series in a high-performant and cost-efficient manner.
Well, it’s a lot harder than it sounds — because logs and time-series are not the same.
This is a post following up on my Monitorama Baltimore 2019 talk.
Logging and Monitoring systems — Observability Systems, if you prefer — often seem to struggle to meet the needs of their users.
Monitoring — the measurement of your system, the gathering of telemetry, and alerting when it behaves anomalously — is key to running large-scale, modern computer systems. But what many developers today don’t realise is that monitoring can be a key part of your design cycle too.
I’ve been programming for many years, and have spent most of the last few years managing development teams. I’ve written plenty of closed source software, and for a time made my living writing open source software too.
One thing stands out: a shared code base does not a software team make.