Ask HN: Were Graph Databases a Mirage?
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.