Agentic AI 维基
AI 博客 / Neo4j vs Memgraph vs FalkorDB vs LadybugDB：为智能体记忆挑一个图存储
AI 博客

Neo4j vs Memgraph vs FalkorDB vs LadybugDB：为智能体记忆挑一个图存储

关于这四个引擎发布过的每一个性能数字，都由某家厂商自己撰写，而它们没有一个测量了智能体记忆真正产生的并发写入负载。真正可核验的三件事——许可证、写入路径的并发模型、你的记忆框架有没有现成驱动——指向一个反直觉的结论。

作者 智能体 AI 维基 28 分钟读完

2025 年有一半的智能体记忆教程推荐的那个嵌入式图数据库，当年 10 月就被归档了；而原因——苹果收购了这家公司——直到 2026 年 2 月才从一份欧盟备案里浮出水面。这才是这个品类里真正会咬人的风险，而没有任何跑分测量它。关于这四个引擎发布过的每一个性能数字，都是某一家厂商自己写的；能被独立核验的，是许可证、写入路径的并发模型，以及你早就选定的那个记忆框架有没有现成的驱动。决定权在这三样手里，而它们指向一个反直觉的方向：这里许可证最苛刻的引擎，集成故事最好；而唯一一个 MIT 许可证的，一个集成也没有。

一览

截至 2026 年 8 月，在智能体记忆与 GraphRAG 技术栈里会出现的四个引擎。

项目最新版本许可证部署形态
Neo4j 2026.07.1（2026 年 8 月）；5.26 LTS 仍在维护 社区版 GPLv3 + 企业版商业许可 JVM 服务端；集群仅企业版
Memgraph 3.12.0（2026 年 7 月） BSL 1.1，2030 年转为 Apache 2.0 C++ 服务端，主要在内存中
FalkorDB 4.20.4（2026 年 8 月） SSPLv1（非 OSI 认可） Redis 模块；2026 年起为 Rust 引擎
LadybugDB 0.19.1（2026 年 8 月） MIT 嵌入式、进程内，磁盘上一个文件

LadybugDB 是 Kuzu 有人维护的续作，在上游仓库归档前后就已立起来，2025 年 11 月公开宣布，此后发布了约二十个版本。下文把它当作一个独立项目来对待，因为十个月、一千多次提交之后，它就是了。

你见过的每一个数字，都来自某家厂商

先从这里说起，因为它能替你省下一周。FalkorDB 发布了对比 Neo4j 的延迟——中位数 55 毫秒对 577 毫秒，p90 108 毫秒对 4,784 毫秒——跑的是 FalkorDB 自己设计的负载。Memgraph 发布了对比 Neo4j 的吞吐——某个查询形状上每秒 32,028 次对 280 次，声称 114 倍——跑的是 Memgraph 自己设计的负载。两组里 Neo4j 都是被比的那个基线，而它自己没有发布过任何可对照的正面对比。最常被引来给 FalkorDB 背书的那个“独立”基准，其作者的结果由厂商在推广，我无法确认其独立性。

这不等于说厂商在撒谎。两家都公布了方法，FalkorDB 还把测试工具开源了，这比多数厂商做得都好。这只是意味着，这些数字回答的是厂商挑的那个问题：对着一个一次性加载好的图做读多写少的查询。而那不是你即将跑起来的那种负载的形状。

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
智能体记忆在每一轮、由每一个会话写入。而跑分测的是另一个方向。

图记忆是一种带读延迟预算的写密集负载。每一轮都会产出必须并入既有图的情节、实体与关系——要和已有内容去重、在事实变化时作废、在被改写时重新计算向量。一万个并发会话就是对同一个存储的一万个并发写入者。然后在这一轮之内，一个混合查询要从向量相似度进入、再向外遍历，快到用户察觉不出来。被拿去跑分的是读的那一半。而决定这套架构成不成立的是写的那一半——也正是这四者真正拉开差距的那一半。

四个引擎，各自到底是什么

Neo4j —— 每个框架都已经会说的那一个

十五年的生态，而在这个品类里这不是怀旧，是决定性特性：LangChain 有第一方包，LlamaIndex 有属性图存储，Graphiti 的核心库把它列在文档最前面，Mem0 支持它，还有一条 Microsoft GraphRAG 的导入路径。向量检索是原生的，而且 2026 年在这上面下了真功夫——量化向量检索 GA、原生向量数据类型落地、索引内过滤到位——官方的 neo4j-graphrag-python 包还提供了先融合向量索引与全文索引、再做遍历的混合检索器。

代价是开放核心那套熟悉的东西。社区版是 GPLv3 且不带集群；一旦你需要高可用，就得买企业版或 Aura，第三方公布的数字把专业档位放在每 GB 每月约 65 美元。它是一个 JVM 服务端，因而无法嵌入；而且它自己的免费档位限制在不同页面上写得不一致，你最好在照它做设计之前先确认一遍。

Memgraph —— 最强的写入路径，以及那道让人绊倒的许可证

默认在内存中运行、带 MVCC，并发写入的故事确实过硬，还有一个在这里很要紧的设计选择：向量索引与顶点、边住在同一个存储层里，被同一套快照与预写日志覆盖，而不是外挂一个存储。全文索引在关系属性上也能用，不只是节点属性。如果你的图放得进内存、瓶颈又在写吞吐，那么就事论事，它是这份名单上最强的引擎。

有两件事拖住了它，恰恰是在智能体记忆这个场景。许可证是 BSL 1.1：内部生产使用没问题，但你不能把它作为服务提供给第三方，也不能拿它构建与之竞争的东西，而且要到 2030 年才转为 Apache 2.0——如果你的产品本身有一部分就是托管记忆，这就是个活生生的问题。而它的集成集合恰好在这个负载所在的位置缺了一块：LangChain、LlamaIndex、Mem0 都支持，但没有 Graphiti 驱动，这就把它挡在了 2026 年多数记忆产品所依托的那套时序知识图谱栈之外。落盘模式有，但被明确标注为实验性。

FalkorDB —— 最苛刻的许可证，配上最好的集成故事

这就是那处值得注意的倒置。FalkorDB 以 SSPLv1 发布，未获 OSI 认可，是这一组里最激进的许可证——把它作为服务提供出去，许可证的效力就会伸到你整套管理与编排软件上。而它偏偏是智能体记忆这块地位最强的引擎：FalkorDB 是 Graphiti MCP 服务器的默认后端，打包在同一个容器里，Neo4j 作为生产环境的备选。Mem0 的支持通过一个插件到位，相关议题在 2026 年 3 月关闭。LangChain 的向量存储直接暴露了混合检索。

技术上它是一个建立在 GraphBLAS 稀疏矩阵之上的 Redis 模块，2026 年间从 C 重写为 Rust，带来了列式执行模型与真正的 MVCC，而 RDB 文件在两代引擎之间保持兼容。向量与全文索引都是原生的，关系上也能建。它有一个货真价实的免费云档位和公开的入门价格，这份透明度胜过 Memgraph。一个叫 falkordblite 的包会捆绑一个自动托管的 Redis，让你不用运维服务端就能在 Python 里跑起来——好用，但那是打包，不是进程内引擎。

LadybugDB —— 唯一真正嵌入式的那个，也是最孤独的那个

列式、基于磁盘、进程内，一个 .lbug 文件，MIT 许可证，自带原生 HNSW 向量检索与 BM25 全文——你可以在一条 Cypher 语句里跑完混合图检索的全部四个阶段，不需要运维任何服务。对于本地优先的智能体、桌面应用，或者绝不能离开设备的按用户记忆，这份名单上没有第二个候选。开发是实打实的：九个月里约二十个版本，我查看的那天还在有提交落地。

两处硬限制。第一是并发规则：单个进程可以打开一个读写数据库并开多个连接，或者多个进程可以只读地打开它，但两者不能混用。这对“一台机器上一个智能体”完全够用，而对共享的多租户记忆则是一票否决——无论读跑分说得多好听。第二是生态：Graphiti 只有一个关于驱动的开放 RFC，没有已发布的实现；Mem0 没有列它；LangChain 的支持是社区包而非第一方；也没有托管云。治理很薄——一个由公司掌控的分叉，核心团队不具名，没有 CLA，也没有公开的维护者名单。

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
把 LadybugDB 那一行对着 FalkorDB 那一行读。这就是这个品类当下开出的交换条件。

Kuzu 的教训：维护状况是一项技术属性

就技术论技术，Kuzu 曾是显而易见的嵌入式之选——快、列式、工程扎实，出自一个正经的学院派数据库研究组。Mem0 在 2025 年把它加为后端，而它成了所有“想要图记忆但不想要服务端”的人的默认推荐。然后公司被收购，仓库在 2025 年 10 月被归档，官网下线，而生态在四个月后才从一份监管备案里知道原因。

接下来发生的事才值得研究。出现了三个分叉。一个——LadybugDB——是真正在维护的。一个是某风投机构的内部分叉，几十个 star，钉在上游快照上。还有一个在归档当天宣布，而据一位 LDBC 维护者的记述，此后十个月基本什么都没做。与此同时，各个框架没等谁，自己做了决定：Graphiti 把它的 Kuzu 驱动标为弃用，附上一句直白的“上游 Kuzu 项目已不再维护”，并让新项目改用 Neo4j 或 FalkorDB。Mem0 至今仍在列表里放着那个已归档的项目。

于是，选了技术上最好那个引擎的用户，最后拿到的是一份驱动弃用通知、一个没有明显答案的分叉抉择，以及一次他们没有排期的迁移。如果你挑的是一个要装下多年累积状态的存储，那么“2029 年谁还在发修复、在什么治理之下发”就是一个承重的工程问题，而不是采购流程的脚注——退出托管智能体运行时用在服务上的那套推理，在这里同样适用于一种文件格式。

图到底是不是正确答案？

在挑之前值得先问一句，因为诚实的成本数据并不好看。微软自家的 LazyGraphRAG 工作报告称，完整版 GraphRAG 的索引成本大约是其精简变体的一千倍，而在质量相当的前提下全局检索的查询成本要高出数百倍——这组数字在 2026 年的文章里被反复引用，但出自一篇 2024 年年底发表的博文，引用时请按那个日期算。在智能体记忆这一侧，图的写入路径同样不免费：在一个记忆框架里打开图记忆，据报道会把小语料上的检索延迟从几百毫秒推到数秒。

图值回成本的地方，是多跳问题、是时序作废——“这条事实在 3 月被另一条取代了”——以及跨会话的实体消解。它不值回成本的地方，是“帮我找出最相似的三个片段”，那件事向量存储做得更快也更便宜。如果你的记忆其实只是一堆文档，一个嵌入式向量存储是更便宜的答案，而图 RAG 讲清了这条界线落在哪里。架在两者之上的那些框架，在 Mem0 vs Zep vs Letta vs LangMem 里做过对比。

什么时候该选哪个

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
先说清你的约束条件是什么。它通常会把选择直接收敛到一个引擎。
情形选择理由
基于 Graphiti 或 Zep 构建FalkorDB，生产可用 Neo4j这是它支持的两个后端；MCP 服务器默认用 FalkorDB。
本地优先或端上记忆LadybugDB这里唯一的进程内引擎。要为自己写集成留出预算。
多租户托管记忆Neo4j 或 FalkorDB并发写入者加上托管云。先拿 SSPL 对着你的产品读一遍。
写吞吐是瓶颈，且图放得进内存Memgraph最强的写入路径、单存储向量索引。确认 BSL 适配你的业务。
你已经在跑 Neo4jNeo4j2026 年的向量工作已经把当初值得搬家的那道差距补掉了大半。
你无法接受非 OSI 许可证Neo4j 社区版或 LadybugDB这一组里只有 GPLv3 和 MIT 两个选项。

可长期沿用的原则：对一个要装下不断累积的状态的存储来说，许可证、并发模型与维护走向都是技术约束，而跑分是营销。这个品类里的每一个性能数字，都由一个对结果有利害关系的一方撰写；它们中没有一个测量了智能体记忆真正产生的那种并发写入负载。把你的约束条件写下来——进程内、多写入者，还是集成得现成——挑那个满足它的引擎，然后在写第一行代码之前，拿许可证对着你的商业模式读一遍。那个你本来会照着延迟图表挑中的引擎，往往正是你一转身它的驱动就被标为弃用的那个。

常见问题

LadybugDB 能安全地替代 Kuzu 吗？

它是唯一有真实活跃度的分叉——自 2025 年 11 月以来约二十个版本、MIT 许可证、提交持续在落地——所以作为代码库，它的状态远好过那个已归档的上游。需要留神的是治理与生态：这是一个由公司掌控、核心团队不具名、没有公开维护者名单的分叉，而且没有任何智能体记忆框架为它提供第一方驱动。采用它，就意味着这份集成归你自己养。

如果我只是内部自用，FalkorDB 的许可证还要紧吗？

纯内部使用的话，基本不要紧。SSPL 咬人的时刻，是你把这套软件作为服务提供给第三方——那时许可证的效力会伸到它周围的管理、监控与编排软件上。如果你的产品就是托管智能体记忆，那正是这份许可证为之而写的情形，这需要一位律师，而不是一篇博文。Memgraph 的 BSL 有一个范围更窄的同类限制。

FalkorDB 和 Memgraph 对比 Neo4j 的跑分可信吗？

信它的方法，别信它的结论。两家厂商都公布了自己跑的是什么，FalkorDB 还开源了测试工具，所以在那些负载上这些数字大概是可复现的。而那些负载是对着一次性加载好的静态图做读多写少的查询，而且由那个稳赢的一方挑选。就我所能查到的，这些引擎都没有经过 LDBC 审计的结果；而智能体记忆那条并发写入路径，它们一个都没测。

智能体记忆到底需不需要图数据库？

只有当你的查询是多跳的、带时序的，或者需要跨会话做实体消解时才需要。构建图要花掉实打实的 token，图写入也会带来实打实的延迟——据报道，在小语料上打开图记忆会把检索从几百毫秒推到数秒。如果你需要的只是对过往对话的语义召回，向量存储更便宜也更快，而且你随时可以在同一批源数据上再加一层图。

那 pgvector、Neptune、Apache AGE 呢？

都可行，也是有意排除在本文范围之外的。Neptune 是 AWS 的托管服务，自带 Graphiti 与 Mem0 支持；Apache AGE 是一个 Postgres 扩展，适合那些宁可只维护一个数据库、也不追求最好图引擎的团队。这里对比的四个，是在 2026 年的智能体记忆技术栈里作为默认项出现的那几个——这是一条与“最好的图数据库”不同的筛选标准。

延伸阅读

本站相关：

项目来源：