Thread by @mdavidallen

#SQL vs. #Cypher for hierarchies

Recursive common-table expressions (SQL)

vs.

built-in path variables in #graph

This only shows part of the picture; with recursive CTEs in #SQL I believe it is the case that:

- You can constrain max recursion, but not minimum without writing extra code

Contrast to cypher:

MATCH (e:Employee)-[:REPORTS_TO*3..5]->(:Employee)

recursive CTEs are a good example of "implementing a graph abstraction on top of something else". Namely the employee table represents a bunch of node instances; the managerID is a relationship, and the CTE implements a graph traversal.

because you have to do this every time you want a new graph operation, and actual graph DBs have such things "built in", it's super unsurprising that the graph database is going to make it easier and simpler.

Use the right tool for the job, basically.

but wait it gets better/worse (depending on your perspective). JOINs are computed at runtime so the deeper you traverse and the more data you have the worse it gets in terms of runtime performance.

in neo4j traversing relationships is really just pointer chasing in memory