"The problem with a join is that you never know what intermediate set will be produced, meaning you never quite know the memory use or latency of a query with a

"The problem with a join is that you never know what intermediate set will be produced, meaning you never quite know the memory use or latency of a query with a join. Multiplying that out with several joins means you have enormous potential for queries to run slowly while consuming lots of (scarce) resources." Anyone with even a meagre understanding of databases will put indexes on join columns. If the data model is complete, then the joined columns will be modelled as foreign keys (conceptually the same as a relationship in a graph DB) which force indexes. I think they are talking more about problems with ORMs, where the ORM might construct unexpected queries that don't hit indexes. This is an ORM problem, not a relational DB problem. One of the major promises of relational DBs was that you could write code describing what you wanted, and the DBMS would figure out how to efficiently find it for you. This promise was derailed by the push to merge relational models with object-oriented models (i.e. ORMs), but it's not dead. What we need is a more powerful SQL, one that doesn't require boilerplate and can do things like recursion (making every database a graph database). We need a SQL that makes the application code seem like boilerplate. We need the equivalent of type inference for joins; let me say A join D and the DBMS infers I mean A->B->C->D and figures out the cardinality of the result. We need result sets that are graphs instead of one-list-fits-all. These are all things that can be modelled in an RDBMS without losing its expressiveness.