Agentic AI Wiki
AI Blog / Neo4j vs Memgraph vs FalkorDB vs LadybugDB: Picking a Graph Store for Agent Memory
AI Blog

Neo4j vs Memgraph vs FalkorDB vs LadybugDB: Picking a Graph Store for Agent Memory

Every performance number published about these four engines was written by one of the vendors, and none of them measures the concurrent-write workload agent memory actually generates. What is checkable — licence, write-path concurrency, and whether your memory framework already ships a driver — points somewhere counter-intuitive.

By Agentic AI Wiki 15 min read

The embedded graph database that half of 2025's agent-memory tutorials recommended was archived in October of that year, and the reason — Apple bought the company — only surfaced in a February 2026 EU filing. That is the risk that actually bites in this category, and no benchmark measures it. Every performance number published about these four engines was written by one of the vendors; the things that are independently checkable are the licence, the write-path concurrency model, and whether the memory framework you already chose ships a driver. Those three decide it, and they point somewhere counter-intuitive: the most restrictively licensed engine here has the best integration story, and the only MIT-licensed one has none.

At a glance

Four engines that turn up in agent-memory and GraphRAG stacks, as of August 2026.

ProjectLatest releaseLicenceDeployment shape
Neo4j 2026.07.1 (Aug 2026); 5.26 LTS still shipping GPLv3 Community + commercial Enterprise JVM server; clustering is Enterprise-only
Memgraph 3.12.0 (Jul 2026) BSL 1.1, converting to Apache 2.0 in 2030 C++ server, primarily in-memory
FalkorDB 4.20.4 (Aug 2026) SSPLv1 (not OSI-approved) Redis module; Rust engine as of 2026
LadybugDB 0.19.1 (Aug 2026) MIT Embedded, in-process, one file on disk

LadybugDB is the maintained continuation of Kuzu, stood up as the upstream repository was archived, publicly announced in November 2025, and shipping roughly twenty releases since. Everything below treats it as a project in its own right, because after ten months and a thousand-plus commits that is what it is.

Every number you have seen came from a vendor

Start here, because it saves you a week. FalkorDB publishes latencies against Neo4j — 55 ms versus 577 ms at the median, 108 ms versus 4,784 ms at p90 — on a workload FalkorDB designed. Memgraph publishes throughput against Neo4j — 32,028 queries per second versus 280 on one query shape, a 114× claim — on a workload Memgraph designed. Neo4j is the baseline in both, and publishes no comparable head-to-head of its own. The "independent" benchmark most often cited for FalkorDB was published by an author whose results the vendor amplifies, and I could not establish independence.

None of this means the vendors are lying. Both publish their methodology, and FalkorDB open-sources its harness, which is more than most. It means the numbers answer a question the vendor chose: read-heavy queries against a graph loaded once. That is not the shape of the workload you are about to run.

Where the graph store sits in an agent memory loop An agent turn produces a transcript that an extraction step turns into entities and relations. Those are written into the graph store on every turn, from many concurrent sessions at once, which is the hot path. Retrieval reads the same store with a combined vector and traversal query inside the turn's latency budget. The write path, not the read benchmark, is what the concurrency model of the store has to survive. Agent turns many sessions at once each one ends in a transcript Extraction entities, relations, episodes plus an embedding per node WRITE, EVERY TURN The graph store concurrent writers from every session plus deletes, merges and re-embeds this is the hot path, and it is a write path READ, INSIDE THE TURN Hybrid retrieval vector entry point, then traversal, in one query back into the next turn's context What the benchmarks measure read latency on a static graph loaded once, by one writer
Agent memory writes on every turn, from every session. The benchmarks measure the other direction.

Graph memory is a write-heavy workload with a read latency budget. Each turn produces episodes, entities and relations that have to be merged into an existing graph — deduplicated against what is already there, invalidated when facts change, re-embedded when they are rewritten. Ten thousand concurrent sessions are ten thousand concurrent writers against one store. Then, inside the turn, a hybrid query has to enter by vector similarity and traverse out, fast enough that the user does not notice. The read half is what gets benchmarked. The write half is what decides whether the architecture works, and it is the half where these four genuinely differ.

The four, by what they actually are

Neo4j — the one every framework already speaks

Fifteen years of ecosystem, and in this category that is not nostalgia, it is the deciding feature: LangChain has a first-party package, LlamaIndex has a property-graph store, Graphiti's core library documents it first, Mem0 lists it, and there is a Microsoft GraphRAG import path. Vector search is native and had real work done on it in 2026 — quantized vector search went GA, a native vector data type landed, in-index filtering arrived — and the official neo4j-graphrag-python package ships hybrid retrievers that fuse a vector index and a full-text index before traversing.

The costs are the familiar open-core ones. Community Edition is GPLv3 with no clustering; the moment you need high availability you are buying Enterprise or Aura, where published third-party figures put professional tiers around $65 per gigabyte per month. It is a JVM server, so it cannot be embedded, and its own free-tier limits are documented inconsistently enough that you should confirm them before designing around them.

Memgraph — the fastest write path, and the licence people trip over

In-memory by default with MVCC and a genuinely strong concurrent-write story, plus a design choice that matters here: the vector index lives in the same storage layer as the vertices and edges, covered by the same snapshots and write-ahead log, rather than in a bolted-on store. Full-text indexes work on relationship properties as well as node properties. If your graph fits in RAM and your bottleneck is write throughput, this is the strongest engine on the list on the merits.

Two things hold it back for agent memory specifically. The licence is BSL 1.1: internal production use is fine, but you may not offer it as a service to third parties or build something that competes with it, and it does not convert to Apache 2.0 until 2030 — which is a live problem if you are a platform whose product is, in part, hosted memory. And the integration set has a hole exactly where this workload lives: LangChain, LlamaIndex and Mem0 are all supported, but there is no Graphiti driver, which rules it out of the temporal-knowledge-graph stack that most 2026 memory products are built on. On-disk mode exists and is explicitly experimental.

FalkorDB — the restrictive licence with the best integration story

This is the inversion worth noticing. FalkorDB ships under SSPLv1, which is not OSI-approved and is the most aggressive licence in the group — offer it as a service and the licence reaches your entire management and orchestration stack. And it is nonetheless the engine with the strongest agent-memory position: FalkorDB is the default backend of the Graphiti MCP server, bundled in a single container, with Neo4j offered as the production alternative. Mem0 support arrived via a plugin closed in March 2026. LangChain's vector store exposes hybrid search directly.

Technically it is a Redis module built on GraphBLAS sparse matrices, rewritten from C to Rust during 2026 with a columnar execution model and real MVCC, and RDB files stay compatible across the two engines. Vector and full-text indexes are native, on relationships as well as nodes. There is a genuine free cloud tier and a published entry price, which is more transparency than Memgraph offers. A package called falkordblite bundles an auto-managed Redis so you can run it from Python without operating a server — useful, but it is packaging, not an in-process engine.

LadybugDB — the only true embedded option, and the loneliest

Columnar, disk-based, in-process, one .lbug file, MIT-licensed, with native HNSW vector search and BM25 full-text — you can run all four stages of a hybrid graph retrieval inside a single Cypher statement with no service to operate. For a local-first agent, a desktop application, or per-user memory that must not leave the device, nothing else on this list is even a candidate. Development is real: about twenty releases in nine months and commits landing the day I checked.

Two hard limits. First, the concurrency rule: a single process may open one read-write database with many connections, or many processes may open it read-only, but you cannot mix the two. That is fine for one agent on one machine and disqualifying for shared multi-tenant memory, no matter what the read benchmarks say. Second, the ecosystem: Graphiti has an open RFC for a driver and no shipped implementation, Mem0 does not list it, LangChain support is a community package rather than first-party, and there is no managed cloud. Governance is thin — a company-controlled fork with an unnamed core team, no CLA and no published maintainer roster.

Four graph stores across the five axes that decide the pick A matrix with four rows for Neo4j, Memgraph, FalkorDB and LadybugDB, and five columns for licence freedom, embedded deployment, concurrent multi-writer support, first-party agent-memory framework drivers, and a managed cloud offering. Neo4j is medium on licence and strong on concurrency, drivers and cloud, but cannot be embedded. Memgraph is weak on licence and drivers, strong on concurrency. FalkorDB is weak on licence but strong on concurrency, drivers and cloud, and only partially embeddable. LadybugDB is the only strong licence and the only truly embedded engine, and is weak on concurrency, drivers and cloud. What actually decides the pick LICENCE EMBEDDED MULTI-WRITER MEMORY DRIVERS MANAGED CLOUD Neo4j GPLv3 core closed EE server only yes every framework Aura Memgraph BSL 1.1 no DBaaS server only yes in-memory MVCC Mem0 yes Graphiti no yes, no public prices FalkorDB SSPL not OSI Redis module lite bundles it yes Rust MVCC Graphiti default Mem0 plugin free tier published price LadybugDB MIT in-process one file one RW process or many RO none first-party none strong partial weak or absent as of August 2026
Read the LadybugDB row against the FalkorDB row. That is the trade the category is currently offering.

The Kuzu lesson: maintenance is a technical property

Kuzu was, on the technical merits, the obvious embedded pick — fast, columnar, well-engineered, out of a serious academic database group. Mem0 added it as a backend in 2025 and it became the default recommendation for anyone who wanted graph memory without a server. Then the company was acquired, the repository was archived in October 2025, the website went down, and the ecosystem found out why four months later from a regulatory filing.

What followed is the part worth studying. Three forks appeared. One — LadybugDB — is genuinely maintained. One is a venture firm's internal fork with a few dozen stars, pinned to upstream snapshots. One was announced the day the archive happened and then, by an LDBC maintainer's account, did essentially nothing for ten months. Meanwhile the frameworks made their own decision without waiting: Graphiti marked its Kuzu driver deprecated with the blunt note that "the upstream Kuzu project is no longer maintained," and told new projects to use Neo4j or FalkorDB. Mem0 still lists the archived project.

So the users of the technically best engine ended up with a driver deprecation notice, a fork question with no obvious answer, and a migration they did not schedule. If you are picking a store to hold state that accumulates for years, "who will still be shipping fixes in 2029, and under what governance" is a load-bearing engineering question, not a procurement footnote — the same reasoning that exiting a managed agent runtime applies to services applies here to a file format.

Is a graph even the right answer?

Worth asking before you pick one, because the honest cost data is uncomfortable. Microsoft's own LazyGraphRAG work reports indexing costs for full GraphRAG that are roughly a thousand times its own lazy variant, and global-search query costs several hundred times higher at comparable quality — figures that circulate constantly in 2026 write-ups but come from a post published in late 2024, so date them accordingly. On the agent-memory side, the graph write path is not free either: enabling graph memory in a memory framework has been reported to move search latency from the hundreds of milliseconds into seconds on a small corpus.

Graphs earn their cost on multi-hop questions, on temporal invalidation — "this fact replaced that one in March" — and on entity resolution across sessions. They do not earn it on "find me the three most similar chunks," which a vector store does faster and cheaper. If your memory is really a pile of documents, an embedded vector store is the cheaper answer and graph RAG lays out where the line falls. The frameworks that layer over both are compared in Mem0 vs Zep vs Letta vs LangMem.

When to pick which

Which store wins under which binding constraint Three columns, one per binding constraint. If the memory must run in-process with no server, LadybugDB is the only real answer and you accept that no memory framework ships a driver for it. If many sessions write concurrently to one shared graph, the server engines are the answer and the embedded one is disqualified by its single-writer rule. If you want the framework integration to already exist, FalkorDB and Neo4j are the answer, and the licence is the cost you pay. It must be in-process no server, one file, ships inside the application LadybugDB WHAT IT COSTS you write the driver Many writers, one graph every session writes on every turn, concurrently Neo4j · Memgraph · FalkorDB WHAT IT COSTS a server to operate It must already plug in the memory framework you picked ships a driver FalkorDB · Neo4j WHAT IT COSTS SSPL, or GPL plus a bill
Name your binding constraint first. It usually collapses the choice to one engine.
SituationPickBecause
Building on Graphiti or ZepFalkorDB, or Neo4j for productionThey are the two supported backends; the MCP server defaults to FalkorDB.
Local-first or on-device memoryLadybugDBThe only in-process engine here. Budget for writing your own integration.
Multi-tenant hosted memoryNeo4j or FalkorDBConcurrent writers plus a managed cloud. Read the SSPL against your product first.
Write throughput is the bottleneck, graph fits in RAMMemgraphStrongest write path, single-store vector index. Confirm BSL fits your business.
You already run Neo4jNeo4j2026's vector work closed most of the gap that would have justified moving.
You cannot accept a non-OSI licenceNeo4j Community or LadybugDBGPLv3 or MIT are the only two options in this group.

The durable principle: for a store that holds accumulating state, the licence, the concurrency model and the maintenance trajectory are technical constraints, and the benchmark is marketing. Every performance figure in this category was authored by a party with an interest in it; none of them measures the concurrent-write workload agent memory actually generates. Write down your binding constraint — in-process, many writers, or an integration that already exists — pick the engine that satisfies it, and then read the licence against your business model before you write a line of code. The engine you would have chosen on a latency chart is the one whose driver gets deprecated while you are not looking.

FAQ

Is LadybugDB a safe replacement for Kuzu?

It is the only fork with real activity — roughly twenty releases since November 2025, MIT-licensed, commits landing continuously — so as a codebase it is in far better shape than the archived upstream. The caveats are governance and ecosystem: it is a company-controlled fork with an unnamed core team and no published maintainer roster, and no agent-memory framework ships a first-party driver for it. Adopting it means owning the integration.

Why does FalkorDB's licence matter if I am just running it internally?

For purely internal use it largely does not. SSPL bites when you offer the software as a service to third parties, at which point the licence reaches the management, monitoring and orchestration software around it. If your product is hosted agent memory, that is exactly the case it was written for, and it needs a lawyer rather than a blog post. Memgraph's BSL has a narrower version of the same restriction.

Can I trust the FalkorDB and Memgraph benchmarks against Neo4j?

Trust the methodology, not the conclusion. Both vendors publish what they ran, and FalkorDB open-sources its harness, so the numbers are probably reproducible on those workloads. The workloads are read-heavy queries against a statically loaded graph, chosen by the party that wins them. No LDBC-audited result exists for any of these engines that I could find, and agent memory's concurrent-write path is not measured by any of them.

Do I need a graph database for agent memory at all?

Only if your queries are multi-hop, temporal, or require entity resolution across sessions. Graph construction costs real tokens and graph writes add real latency — enabling graph memory has been reported to push search from hundreds of milliseconds into seconds on small corpora. If what you need is semantic recall over past conversations, a vector store is cheaper and faster, and you can add a graph later over the same source data.

What about pgvector, Neptune, or Apache AGE?

All viable and deliberately out of scope here. Neptune is a managed AWS service with its own Graphiti and Mem0 support; Apache AGE is a Postgres extension that suits teams who want one database rather than the best graph engine. The four compared here are the ones that turn up as defaults in 2026 agent-memory stacks, which is a different selection criterion than "best graph database."

Further reading

On this wiki:

Project sources: