LLM Agent 图记忆成本:Corvic AI 与 7 款图数据库对比
Graph Memory for LLM Agents: At What Cost? A Comparative Evaluation of Query, Ingest, and Update Performance Across Graph Database Engines
想给 Agent 配图记忆数据库前先看这篇,Corvic AI、Neo4j 等 8 款引擎实测,最贵的不是查询慢,是把数据喂进去。
评测团队构建了一个含 102 万节点、534 万行数据的生物医学风格属性图,并设计 20 条覆盖邻域查找、反连接、聚合、top-k 排序、时间过滤等场景的查询。测试对象为 Corvic AI 列式引擎与 LoraDB、Ladybug、DuckPGQ、Memgraph、Neo4j、HugeGraph、FalkorDB 共 7 款图数据库系统。结果显示没有系统全面最快:Ladybug 在窄邻域查询上占优,Corvic AI 在大范围扫描和连接查询上更快,DuckPGQ 仅因查询计划选择就明显偏慢。各引擎批量摄取吞吐从 5.0k 到 430 万行/秒不等,相差 3 个数量级;交叉点计算表明,每次数据刷新后查询量低于约 10 万次时,摄取成本主导总拥有成本。
Graph Memory for LLM Agents: At What Cost? A Comparative Evaluation of Query, Ingest, and Update Performance Across Graph Database Engines
Graph databases are frequently positioned as categorically necessary for connected-data workloads, yet the systems dimension along which they actually differ - query planning, indexing, and data-readiness cost - is rarely isolated from vendor framing. We construct a synthetic, biomedical-shaped property graph (1.02 million nodes, 5.34 million total node and edge rows) and a twenty-query workload spanning neighborhood lookups, bounded paths, set intersections, anti-joins, grouped aggregation, top-k ranking, temporal filters, full scans, and relational joins. We benchmark Corvic AI - a purpose-built columnar query engine underlying Corvic's ontology management layer ("memories")- against seven purpose-built or graph-extension database systems (LoraDB, Ladybug, DuckPGQ, Memgraph, Neo4j, HugeGraph, and FalkorDB) at three graph scales spanning three orders of magnitude. We report query latency geomeans, bulk-ingest throughput, point-update latency, and answer correctness for each system, and we derive a simple total-cost-of-ownership model that expresses the ingest/query trade-off as a function of query volume. Our central finding is that no system in this sample is categorically fastest: a native graph engine (Ladybug) outperforms Corvic AI on narrow, bounded-neighborhood shapes, while Corvic AI is faster on shapes that scan or join a large fraction of the graph, and a system implementing graph query syntax via SQL/PGQ (DuckPGQ) is measurably slower purely due to query-plan choice. The dominant cost differential in our data is not query latency but the cost of making data queryable at all: bulk-ingest throughput varies by three orders of magnitude across engines (5.0k-4.3M rows/s), a gap that a simple crossover-point calculation shows dominates total cost for any workload with fewer than roughly 105 queries per data refresh.