What is easy to do in a relational DB that is hard to do in a graph DB like Neo4j?

[cdeszaq]

It seems like everything I read says that graph DBs are always better than a relational DB, but that just doesn't make sense to me. There has to be some fairly common cases where a graph DB is not the best choice.

So, in an effort yo try to better understand when to choose what tool to use for a particular job, when is an RDBMS a better choice than a graph DB?

To get the ball rolling, one possible case would be where one needs to find things than an entity isn't connected to, filtered along various dimensions.

[Michael Hunger]

All kinds of data analysis that you perform on precomputed large denormalized tables with according indexes.

[Craig Taverner]

A simple case would be when you have moderate amounts of data with a very stable schema, which would be good to visualize in a table. Then a tabular database becomes a natural choice. The fact that every record must have the same fields is a restriction that is actually very convenient in many ways. But the more complex the model (more tables), the less ideal it is.

It is also very hard to say where to draw the line when the graph becomes easier. I think it depends on the domain and the developers mind-set :-)

One way I considered looking at this is to consider the reasons for when a graph is better, and take the opposite:

• So, one reason to consider neo4j would be when you have schema's that change a frequently. This is applicable to all of nosql. The converse is that if you have a stable schema, perhaps a rdbms is better for you.
• Another case is for very large amounts of data (most nosql scales insanely well, and neo4j scales quite well, and the wins are mostly in the superb traversal performance leading to super performance gains for particular types of queries). The converse of this would be that small amounts of data might do well in a rdbms.... hmm... not really true, it is more like saying that the differentiating factor is removed with small amounts of data.
• A third case could be complexity. The graph is better for modeling very complex systems mainly because the graph is a more natural model. So the converse would imply that simpler systems are better in a table. Again, this seems more like a case of reducing the differentiating factor, not finding an opposite.

In summary, moderate amounts of data with stable schemas and moderate complexity could be well modelled in rdbms. This is over simplistic, of course, since the real cost/benefits balance needs to be determined on a case-by-case basis, but perhaps it is a start.