GraphRAG made graph databases interesting to people who had never drawn an edge in their lives. The pitch is simple: vector search retrieves chunks that look similar; a knowledge graph retrieves facts that are connected — multi-hop relationships, entity disambiguation, the "how is A linked to B" question that top-k similarity can't answer. Once you decide you need a graph backend under your agent's memory or your retrieval layer, you hit the actual question: which engine?
The internet will answer with benchmarks. Ignore most of them. Every vendor publishes a chart on which it wins, run on a graph shape and query mix chosen to make it win. The decisions that will actually follow you for years are two axes nobody puts on the benchmark slide: where your graph lives in the memory hierarchy, and which restrictive license you can live with.
Neo4j: the incumbent, with a copyleft catch#
Neo4j is the default for a reason. It invented Cypher (now the basis of the ISO GQL standard), it has the deepest ecosystem — the Graph Data Science library, APOC, mature drivers in every language — and it ships an official GraphRAG package plus a whole GenAI ecosystem of integrations. Its disk-based engine with a tunable page cache is the only one of the three that comfortably holds a graph bigger than your RAM.
The catch is the license. Neo4j Community Edition is GPLv3 — genuinely open source, but copyleft, which means embedding it inside a closed product is a legal conversation, not a pip install. The clustering, security, and backup features you'll want in production live in the commercial Enterprise Edition. And the JVM page-cache model that lets it scale past RAM is also why a cold instance can take the better part of a second to answer its first query.
FalkorDB: a graph as a sparse matrix, built for many tenants#
FalkorDB is the most interesting architectural bet of the three. It picked up the abandoned RedisGraph and runs the graph as GraphBLAS sparse adjacency matrices inside a Redis process — which turns multi-hop traversal into linear algebra (matrix multiplication) and gives it genuinely low cold-start latency and fast expansion.
Its real differentiator for agent systems is multi-tenancy. Because each graph is just a key in Redis, FalkorDB is built to hold thousands of small graphs in one instance — one knowledge graph per user, per tenant, or per agent. That is exactly the shape a lot of GraphRAG and agent-memory systems need, and it's awkward in Neo4j's heavier one-database-per-graph model. FalkorDB also ships a GraphRAG-SDK that auto-generates an ontology from unstructured text. The license is SSPLv1 — source-available, fine for internal use, restrictive if you plan to offer it as a service.
Memgraph: in-memory, real-time, Cypher-compatible#
Memgraph is the in-memory specialist. Written in C++, Cypher-compatible, with the MAGE algorithm library and first-class streaming (Kafka) ingestion, it's built for real-time workloads where the graph is changing and queries must be fast.
The tradeoff is literal: your working set has to fit in RAM (there's an on-disk mode, but in-memory is the whole point). Memgraph Community is BSL 1.1 — source-available, converting to an open license on a delay. For a streaming, low-latency agent that rebuilds context constantly and whose graph fits in memory, it's the speed play.
The license is the buried lede#
Here's the thing the comparison posts skip. Look at what's not on the list: a permissively-licensed, actively-maintained graph engine purpose-built for GraphRAG. There used to be one.
Kuzu was the MIT-licensed embedded graph database — "SQLite for graphs," with vector and full-text search built in. In October 2025 its sponsor archived the repository and walked away. The most permissive option in the category is now a tombstone with a community fork.
That archiving (HN thread) is not gossip — it's a design input. It means every viable choice today is restrictive: GPLv3 (Neo4j), BSL (Memgraph), or SSPL (FalkorDB). And it's a reminder that an embedded graph engine is only as durable as the one company maintaining it, which is a real risk to weigh when the database is load-bearing for your agent's memory.
How to actually choose#
- Neo4j when you want the deepest ecosystem and official tooling, and especially when your graph will outgrow RAM. Accept the GPLv3/commercial split.
- FalkorDB when you need many small per-tenant knowledge graphs in one instance and low-latency multi-hop retrieval — the native shape of multi-user GraphRAG. Accept SSPL.
- Memgraph when the graph fits in memory and the job is real-time, streaming, low-latency. Accept BSL.
All three now keep vectors next to the graph, so for most GraphRAG builds you won't need a separate vector store at all. But before you reach for any of them, be honest about whether your retrieval actually needs edges — if top-k over chunks answers your queries, a plain vector database is the simpler tool, and GraphRAG is the wrong default. Pick a graph engine when the relationships are the answer.
