It is not about the underlying database structure, it is about complex, "branchy" relations and querying them, including properties of the relations themselves.

It is not about the underlying database structure, it is about complex, "branchy" relations and querying them, including properties of the relations themselves. Relational databases are not good with recursive join queries made against the same table. Reusing a recent example: MATCH (a:Account)-[t:Transfer*]->(b:Account) WHERE a.country = 'Canada' and b.name = 'John Doe II' and t.transfer_type = 'international' RETURN a.ID Which is… "show all accounts that have made international money transfers into John Doe II's account who lives in Canada. Source and target "table" is the same in this example. It is much simpler and more efficient to use a graph database especially to make a complex query where a leaf node circles back either to a "source" or to any intermediate node using the same or a new relationship. SQL will look nightmarish and will likely require manual hints to the query planner / optimiser. Graph databases also allow to add (as well as delete) new relationships in an incremental and non-invasive fashion, as they become discovered – a useful feature for the analysis of a large or unknown dataset. Graph databases require valid use cases, though, and they are not a generic substitute for a RDBMS (or for a random NoSQL database).