7 ms·

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 interv

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 https://github.com/FoundationDB/fdb-document-layer

bryanrasmussen 1y ago
>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.
- aabhay 1y ago
  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.
  - jlokier 1y ago
    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.
    - hobofan 1y ago
      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.
  - dboreham 1y ago
    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.
sorobahn 1y ago
What were some of the pain points mentioned?
- chaps 1y ago
  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 https://graphql-docs-v2.opencollective.com/queries/account (navigate to the variables tab for a real mindfuck)
  - OrangeDelonge 1y ago
    And GraphQL is related to Graph databases how exactly? Just because they both have the word graph in them?
    - chaps 1y ago
      Heh, you're right I got it wrong but there's really no need for your weird aggression. Cheers.
  - dleeftink 1y ago
    It's unfortunate GrapgQL co-opted the terminology because it's quite different from the kinds of graphs these databases attempt to model.
- kirubakaran 1y ago
edude03 1y ago
> 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.

bryanrasmussen 1y ago

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

aabhay 1y ago
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.
- jlokier 1y ago
  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.
  - hobofan 1y ago
    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.
- dboreham 1y ago
  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.

sorobahn 1y ago

What were some of the pain points mentioned?

chaps 1y ago
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 https://graphql-docs-v2.opencollective.com/queries/account (navigate to the variables tab for a real mindfuck)
- OrangeDelonge 1y ago
  And GraphQL is related to Graph databases how exactly? Just because they both have the word graph in them?
  - chaps 1y ago
    Heh, you're right I got it wrong but there's really no need for your weird aggression. Cheers.
- dleeftink 1y ago
  It's unfortunate GrapgQL co-opted the terminology because it's quite different from the kinds of graphs these databases attempt to model.
kirubakaran 1y ago

edude03 1y ago

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