Hacker News Reader

Comment by fidotron | Hacker News Reader

Graph databases are one of those things that sound neat but you'll be hard pressed to find people using them that don't regret it.

I memorably had a job interview which consisted almost entirely of their senior architect going over exactly why he regretted introducing Neo4J several years earlier and how all the work is really about getting away from it. That was just the most extreme example.

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. There was even a mongo DB compatibility layer for foundation DB, but it doesn't seem to be maintained sadly. https://github.com/FoundationDB/fdb-document-layer

View on HN

>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.

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.

> why he regretted introducing Neo4J

Even for use cases Graph dbs knock out of the park Neo4j (historically, I haven't used it in like 10 years) didn't work very reliably compared to modern competitors.

But as always it's about picking the right tool for the job - I tried to build a "social network" in mysql and neo4j, and (reliability aside) neo4j worked way better.

What were some of the pain points mentioned?

Having worked with SQL for many years now, I truly disliked using graphql when I used it. Most of the time all I need is just a csv-like structure of the data I'm working with and I had a very difficult time with just getting something like that. Joining tables tended to be difficult where the pivot points between relationships was rather semantically unbounded, so it was difficult for me to create a reasonably rigid mental model of the data I was working with. That was especially noticeable in some of the API documentation I worked with -- where a simple REST-like API just gives a simple, usually flat, json... graphql api responses were deeply nested and often in implementation-dependent ways[1] of thousands of lines. Which has IME made explorability practically impossible.

GraphQL implementations have consistently felt like a hobby project where implementing it in an API becomes a thing to put on a resume rather than making a functionally useful API.

[1] https://graphql-docs-v2.opencollective.com/queries/account (navigate to the variables tab for a real mindfuck)

And GraphQL is related to Graph databases how exactly? Just because they both have the word graph in them?

Heh, you're right I got it wrong but there's really no need for your weird aggression. Cheers.

It's unfortunate GrapgQL co-opted the terminology because it's quite different from the kinds of graphs these databases attempt to model.

IME the dreaded out of memory error. This is all they have to say on the matter: https://neo4j.com/developer/kb/recommendations-for-recovery-...

Essentially that using the graph DB prevented any imposition of order or discipline on the structure of the data, due to the constant need to import new customer data in subtly different structures to keep the business running, which led to a complete inability to deliver anything new at all since no one could make assertions about what's in there. Since they couldn't change it without risking breaking a customer they were migrating one customer at a time to a classic RDBMS. (There were like 200 customers, each of which is a company you've probably heard of).

Many will go "you need a proper ontology" at which point just use a RDBMS. Ontologies are an absolute tarpit, as the semantic web showed. The graph illusion is similar to that academic delusion "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." which is one of those quips that makes you appreciate just how theoretical some theoreticians really are.

Reply on news.ycombinator.com