[mrjn]

[Author of Dgraph]

> Query optimizations can be difficult.

I don't think they're any more difficult than SQL really. In fact, with Dgraph we can avoid scans, where SQL has to scan for most of the queries.

In fact, we're aiming to work on query optimization in depth starting mid-May. So, perhaps in a few months, this would be a topic worth writing a blog post about.

[daemonk]

Thanks for the response. I look forward to it. I've used both Dgraph and RedisGraph for some toy projects previously. I really think that graph dbs are the way to go for storing biological/health data which I am involved in. They naturally model this type of data very well.

The query optimization issue seems more to do with how the data is structured than perhaps the query engine? For example, if I wanted to query for all node type X, starting from node type A, it can potentially take a very very long time. But if I add a few known constraints like query all node type X, starting from node type A that paths through node B, C, D. It quickly gets much faster. I guess it's really more up the user to optimize the queries in these cases.

And the flexibility that graphdbs afford to the user makes it hard to realize that perhaps there are these natural constraints that can be used for this query. So it seems like there is definitely a graph analysis component to this that gives you the insight to write the queries faster.

I guess this problem also only applies to natural world problems that you are trying to force into a graph structure rather than a pre-designed database.

[mrjn]

The thing about Dgraph (and potentially other graph DBs) is that it knows the "cardinality" of the relationship, because of the way it stores data. So, it can make judgement calls on the best path to execute a query.

I might have a better write-up about this in a quarter or so.