Our great sponsors
-
Memgraph
Open-source graph database, tuned for dynamic analytics environments. Easy to adopt, scale and own.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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.
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.
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
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