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.