Hacker News Reader

Comment by bryanrasmussen | Hacker News Reader

>The truth that people here don't like is that the Couch/Mongo style document DB is far more compelling as a intermediate point of structured/unstructured.

in my opinion Graph DBs should only be used for highly structured data, which after all is what a graph is. Generally anything you would represent in SQL with too many joins to do queries you commonly have to do.

View on HN

What’s so much more compelling about a graph db than a “with recursive” sql call? And even such recursive sql calls should be fairly rare since you would rather cache frequently accessed foreign key relationships anyway.

Among other things, some graph DBs are designed to perform the equivalent of "with recursive", filtering by attributes as you chase links and/or calculating statistics over subgraphs, more efficiently than SQL databases.

If you're just pulling up a tree of comments on an article using parent-child relations, SQL will be fine, though for query latency you might be better off with a "flat list" article-comment relation instead and recovering the tree structure after fetching the comments.

I've yet to see any of the typical commercially available graph databases do anything fancy in that regard.

If you dive into the query plans of a graph DB you quickly see that there is nothing special about that. In the end it boils down to the same physical joins on node and vertex tables. The only thing graph DBs offer over your typical RDBMS is nicer syntax (while having worse operational maturity), and with the advent of SQL/PGQ event that advandtage is going away.

Under the hood they're basically the same (modulo graph databases are generally less mature and less featureful in their storage implementation). The main difference is impedance match with the human writing the query. Graph databases offer query language semantics that are easier to write and reason about, for graphy workloads.

Reply on news.ycombinator.com