Is this really so hard to believe? Lots of things that are "Default" are just that way for historic purposes. One example, and I say this as someone who's generally a fan of the language, would be Java - it's taught in so many schools, because it's taught in so many schools.

Everyone says things like "You don't need a graphdb" because their default assumption is that there is a cost relative to rdbms, that's the bias of knowing rdbms. The "you don't need X" is one of the most common tropes, I read those words roughly every day on HN.

As a user of a graph database I'm quite pleased with the experience. I can model things extremely naturally, and relationships are dead simple to express.

Did I need a graph database? No, obviously, I could have used any database, but a graph matched my requirements.

There were two lines held up for mocking.

The first one described relational DBs as a software engineering fail. That's patently absurd. (If that's failure, what would success look like?)

You addressed the second one, which is slightly less absurd. You were taught relational DBs because they are enormously widely used. And why are they used so widely? Because they work.

What the article should be saying is, "Here's this approach that works better than relational, and here's how and why it works better." Mocking relational DBs, as if they had been a failure, just makes the authors look clueless.

Yes, I only addressed the part I agreed with. I'm not the author or trying to defend the entire article, just saying that I strongly agree with entrenched technologies being entrenched for very weak reasons. Do I think relational databases have no merit? IDK, probably not, though I haven't chosen to use one in a very long time.

Well... entrenched technologies can be entrenched for very weak (or, if you prefer, path-dependent) reasons, over other technologies that are approximately as good. I'm not sure that lesser technology gets entrenched against clearly superior technology very often. (I mean, there's COBOL...)

Graph databases may be as good as relational DBs. They may be better for some use cases. Are they significantly better for many (say, the majority) of use cases? No? Well then, it's really not an issue that they're what became entrenched, is it?

(And if your answer was "yes" instead of "no": That takes some evidence to believe. And the way this article was written leads me to think that they don't actually have any such evidence.)

I think the problem is that we have a very weak understanding of "better" or "worse" or "use cases". What would a better database look like? Maybe it's faster, or more stable, etc. But if what makes it better is that it is a better model, you end up with religious wars - it's the same reason why no one can really agree on whether a static or dynamic language will lead to "better" code, it's just too hard to tell.

As a user of KV stores and graphdbs myself I would have to use a traditional rdbms. It's been an absolute breath of fresh air being able to express queries in a graph-oriented way. For me the combination has been totally "better", but of course, that's not evidence based! Nor, really, could it be.

> As a user of KV stores and graphdbs myself I would have to use a traditional rdbms. It's been an absolute breath of fresh air being able to express queries in a graph-oriented way. For me the combination has been totally "better", but of course, that's not evidence based! Nor, really, could it be.

Well, it's anecdote. But if a statistically-significant number of people feel that it's "an absolute breath of fresh air", that's totally "better" in a very concrete sense.

Historical entrenchment is not a chance occurrence.

I didn't say it was.