I’ll see your `FLUSHDB` and raise you a `DROP TABLE foo`.<p>Or one that’s actually more likely: `DELETE FROM foo WHERE <insufficiently selective clause follows>`<p>Every “boring” database I can think of offers many such foot-guns, waiting to be used.<p>> Engineers should not spend their careers intimately memorizing random quirks of the infrastructure they use. They deserve better. They deserve boring.<p>In my opinion, this is a little nonsensical and reeks of the no-ops movement. I’m very excited to see what becomes of Dragonfly over the next few years (Redis needs some competition, I feel) but I will be gobsmacked if they produce a product that somehow requires no infrastructure engineer to memorize its quirks.<p>I mean, for starters, “quirky” is highly subjective. But more to the point, I’ve never met a piece of software that somehow meets everyone’s expectations in all cases. It’s definitionally impossible.<p>Set your goals high and all, but at least make them achievable!
I've never heard of Dragonfly before this, and I see it's a Redis competitor, but the examples here <i>really</i> stretch the definition of what it means to be "not boring."<p>> how your junior team member ran "flushdb" in production and caused your service traffic to stall<p>FLUSHDB removes all keys from the database which, depending on your application, could indeed cause a lot of problems. But this seems pretty boring to me: the "delete all data" command deletes all data. Yes, the consequences of doing this on a production application are going to make sure someone's writing a COE, but this doesn't strike me as anything unexpected.<p>edit: This might be more about sync deletes causing outages, but it's really pick your poison here. Which is less boring, "I ran delete and the database locked" or "I ran delete and did a read but the data was still there?" Really up to you.<p>> how your engineering team spent a month tuning the Redis engine before Christmas<p>"Boring" doesn't mean "not tunable" or "one-size-fits-all." MySQL and Postgres are two relatively ancient databases that most people would consider to be really boring, yet they have endless options for performance tuning. Even in todays cloud-first devops-first era, people still make a living off being DBAs, where tuning these systems is their primary job.<p>If anything, I would be much more wary of a system where the configuration <i>isn't</i> exposed to the user, and the engine uses some heuristics to figure operating parameters out without any way to tweak it. To me, <i>that</i> seems a lot less "boring."
> And unless you enjoy telling war stories about how your junior team member ran "flushdb" in production and caused your service traffic to stall, or how your engineering team spent a month tuning the Redis engine before Christmas —you should really think whether this is how you want to spend your time. Engineers should not spend their careers intimately memorizing random quirks of the infrastructure they use. They deserve better. They deserve boring.<p>I'm not sure this person understands infrastructure. I can't think of very many datastores that weren't boring... until you got 50% more traffic in a week, until a rack that 10% of your capacity is in fails, until someone's code update caused a DDOS resulting in requests going to the machine taking 100ms in stead of 1ms.<p>So does boring mean it scales trivially and tolerates failure in well defined ways?