Ask HN: Were Graph Databases a Mirage? | Hacker News Reader

Ask HN: Were Graph Databases a Mirage?

6 pointsAgoRapide8 comments

Are graph databases abandoned but no notice was posted about it anywhere?

I have worked with graph databases for about a year. I am becoming concerned about their effectiveness.

When googling it seems that all discussion is something like two or three years old, and that there is no recent development. The solutions offered often appear as kludges. "The (sorry) State of Graph Database Systems" talk by Peter Boncz kind of sums it up.

More specific, my concerns are as follows:

Performance: The elegant Cypher query language makes it easy to construct queries, but the actual execution is often not performant. It appears that only very simple query strategies are utilized in the database engines. Are the graph engines actually capable of analyzing the data, in order to plan for best performance? Something as elementary as recognizing tree structures inside the graph and traversing them in a performant manner?

Ingress capability: For moderately sized queries the query planner is either extremely slow or just unable to analyze the query at all. This happens also for insertion of what is essentially a sub-graph, touching only one or two existing nodes in the database.

Memory usage and startup time: Are the database engines just "cheating" by reading everything into memory? With corresponding long startup time? If that if so, why should I not just create my own engine, tailored to my specific data?

Scaling: This is related to the above mentioned issues. Are graph databases currently just toys?

My hands-on experience so far is with RedisGraph (including FalkorDB) and Neo4j.

Relational databases have a much longer history of development, and much more engineering time has went into designing RDBMS. It is not a surprise that they are mature on more levels. By looking at the age of a product, you can get a sense of how mature RDBMS systems are compared to most GraphDB projects.

I assume you really like the RedisGraph, now if you think about how much time of development did the RedisGraph had, 5 years? For example, Postgres is 37 years old :D

Horizontal scaling is hard in GraphDBs due to the nature of how the graph is structured and how you interact with it. Jumping across different servers is expensive. This is not a trivial problem that requires a lot of work and investment that Graph-based engines didn't have time to receive.

When we come to the Cyhper, it is easy to shoot yourself in the foot; that is true. It takes time to get used to tricks with Cypher and to know how to use it properly.

Performance, ingress, memory usage, etc is very specific per each system architecture so it is hard to comment.

This brings me to the actual workload, GraphDB/Graph analytical engines, and Knowledge Graph solutions will have their place under the sun, the more complex the use-case the more value the products will bring.

Just look what Deep Mind is doing with GNN and graph tech today: https://deepmind.google/discover/blog/millions-of-new-materi...

But what Peter said it should not be used in simple use cases where the cost of ownership does not bring value because the underlying problem is fairly simple, and Postgres is Free after all.

Disclaimer: I work for Memgraph https://memgraph.com

It's not possible to escape tradeoffs. To deal with tradeoffs, focus is important. API to tradeoffs is also important.

I bet somebody will raise a similar question in a few years time when the list under https://db-engines.com/en/ranking/graph+dbms will be bigger.

DISCLAIMER: Coming from https://github.com/memgraph/memgraph

Relational databases got advanced enough (with recursive CTE's in SQL, and soon with the newly standardized Property Graph Query, which adds a much welcome bit of syntactic sugar) that there's just no point to a general purpose graph DB - plain old RDBMS can serve that use case just as well. "Graph" based systems might still be useful for doing highly advanced, math-based network analysis on large sets of data, but that's a very different thing.

So the easy "instant" graphs offered by Cypher engines are just temptations then?

Looks like a SQL foundation and a solid database engine is better (as always).

You're making me wonder: What's the difference between a graph DB and an ontology/knowledge graph?

We are actually working with semantics / ontologies. The graph database is just our engine for storing the data. I am starting to think whether an ordinary SQL database could be just as useful.

Very interesting. What did they used to use back in the day? SPARQL? This wiki article indicates that it should be possible to store triples in a RDBMS

https://en.wikipedia.org/wiki/SPARQL#Advantages

So far I see more value in ontologies than graph databases. When using established ontologies naming does not become an issue and exchanging / understanding data becomes easier. You also push some of your code to the database "as data" and can reason on it better.

Reply on news.ycombinator.com