[db] Migrating from Kuzu - Analysis of Neo4j, FalkorDB, Memgraph, and other graph database vendors
WIP: This issue is a work in progress
Given the sudden deprecation of Kuzu, the GKG team will be accelerating it's efforts to consider alternative graph databases that strongly overlap with Kuzu's querying capabilities and general performance, while also looking to ameliorate some of the downsides of Kuzu.
The intent of this issue is to provide a broad analysis of the features deemed necessary to the GKGaaS effort, an overview of how each database performs, and some notes on deployment/resource provisioning for each DB.
Neo4j
Neo4j shall be treated as our "boring solution" base case.
FalkorDB
FalkorDB is a Redis Module (analogous to a Postgres Extension), that uses GraphBLAS to implement various graph traversal algorithms necessary for compatibility with OpenCypher, while deferring to Redis for storage, transactionality, durability, and support for horizontal and vertical scaling.
Regarding exactly how FalkorDB integrates with Redis, please see: https://docs.falkordb.com/getting-started/configuration.html, but at a high level, FalkorDB dynamically links their graph traversal and storage utilities at runtime to Redis via the LOAD MODULE command, and FalkorDB communicates with the Redis internals using their C ABI. Thus, the surface area of Falkor is much smaller than entirely de-novo graph database efforts like Kuzu, and connecting to a FalkorDB instance is identical to connecting to a vanilla Redis cluster, assuming the LOAD MODULE command is called. One benefit of extending Redis versus adding a new stateful service is that GitLab already deploys Redis in production: https://docs.gitlab.com/charts/advanced/external-redis/.
Nebula Graph DB
Memgraph
Honorable Mentions
- Apache AGE
- Dgraph
- DuckPGQ
- GFQL