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.
