21–30 of 56 posts
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 he…
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 he…
What were some of the pain points mentioned?
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)
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 he…
>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.
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 he…
What were some of the pain points mentioned?
I'm building https://www.ergodic.ai - and we are using a graphs as the primary objects in which the intelligence operates. I don't think every graph needs a graph database. For 99% of use-cases a relational database is the preferred solution to store a graph: provided that we have objects and ways to link objects, we're good to go. The advantages of graph dbs are in running more complex graph algorithms whenever that…
> For 99% of use-cases a relational database is the preferred solution… After enough years you realize this is the case for every single problem
Earlier quoted context omitted.
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…
This is not agentic but pretty good results when I did a poc.
Earlier quoted context omitted.
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…
And GraphQL is related to Graph databases how exactly? Just because they both have the word graph in them?
If it is just to query one single dataset that is already in one tool it is less compelling.
So far, I'm using postgres and helping the agent develop MCP functions for it. As we find some optimizations (or at least, reliably performant daily routines), I might make the choice to represent some relationships in a graph database.
One thing I'm building that seems plausibly likely to eventually call for a graph DB is "The Oracle of Bluegrass Bacon" (like the Oracle of Kevin Bacon, but for string band pickers). And it's nice for the agent to have fairly optimal access to this data as we build other adjacent projects.
But yeah, so far just postgres.