KuzuDB for Production AI Agents: Our Fork, the Benchmarks, and Why Graph Memory Works

Why Agents Need Graph Memory

At Vela we are constantly running experiments that push the limits of what autonomous agents can do. As a quant venture capital firm we think beyond a single asset class, and part of that means stress-testing agent architectures in domains where the feedback loops are fast and unforgiving, the way an AI-native hedge fund would test its models against live markets. That work is where we first needed graph memory: agents making continuous decisions need to remember what worked and why. A relational database tells you what happened, but it cannot efficiently answer why.

The pattern generalizes to any multi-agent domain. Consider a venture capital workflow as an example:

• "Which founder backgrounds consistently predict Series A success within 24 months?"
• "What early signals appeared across the best-performing portfolio companies before their breakout?"
• "Show me all investments where founding teams with prior exits raised follow-on rounds within 18 months."

These are multi-hop traversals across a causal chain: Founder →[founded]→ Company →[raised]→ Round →[resulted_in]→ Outcome. In SQL this requires joins that compound with each hop. In a graph database it is a single path query, and the query cost stays flat as the graph grows. The same pattern applies to any domain where agents need to reason about chains of cause and effect.

“The path from signal to outcome is causal. Causal structure is queryable, but only if you store it correctly.”

Why We Chose KuzuDB Over Neo4j

KuzuDB runs in-process via pip install kuzu. No server, no Docker, no ops overhead. In a typical multi-agent system with a five-second total decision latency budget, Neo4j at 3–4 seconds per path query consumes that before inference even runs. KuzuDB at 9ms leaves the headroom agents need.

Benchmarks: KuzuDB vs Neo4j

From P. Rao's kuzudb-study, testing 100K nodes, 2.4M edges, identical hardware:

What a Query Looks Like

KuzuDB implements openCypher, the same query language as Neo4j. All queries are portable. To illustrate, imagine you want to find which founder backgrounds predict fast Series A raises. The graph query would look like this:

// Which founder backgrounds predict Series A success?
MATCH (f:Founder)-[:founded]->(c:Company)-[:raised]->(r:Round)
WHERE r.stage = 'Series A'
  AND r.months_to_raise < 24
RETURN f.background,
       COUNT(*) AS successes,
       AVG(r.months_to_raise) AS avg_months
ORDER BY successes DESC LIMIT 5

Three hops: among companies that raised a Series A within 24 months, which founder backgrounds appear most often? In SQL this requires two joins and a subquery. In Cypher it reads like the question you are asking.

The KuzuDB Fork Landscape in 2026

The original team archived KuzuDB in October 2025. The engine is stable. This was not an abandonment mid-crisis, but active development stopped. Here is where things stand:

Before we list the forks, credit where it is due. Semih Salihoglu and the KuzuDB team at the University of Waterloo built something remarkable: a genuinely novel graph database grounded in serious database research (worst-case optimal joins, factorized execution, vectorized processing), published at CIDR 2023 and open-sourced under MIT. The engineering quality of the codebase is exceptional. Everything we and other forks build on top of exists because of the foundation Semih and his team laid. We are grateful for their work.

Why we forked instead of migrating

The original KuzuDB allows only one writer at a time. In our architecture multiple agents write to the context graph simultaneously. Serialized writes would bottleneck the entire system and get worse as the agent count grows. We added concurrent multi-writer support. We now own this dependency fully, pull improvements from the community selectively, and carry no upstream abandonment risk.

What Memory Unlocks

Persistent learning. Discovered patterns are stored as graph nodes with confidence scores, updated with every new decision. Agents query them before acting.

Cross-session continuity. When an agent restarts it loads full prior context from the graph instead of starting cold.

Social learning. Top-performing agents write validated patterns to shared partitions. Underperforming agents can be diagnosed by querying which conditions dominate their worst outcomes.

Causal auditability. Every decision is traceable: which signal, under which conditions, triggered which agent to place it, and what outcome resulted. The graph is the audit log and the active knowledge base at once.

Connection to Vela's Research

Vela's Oxford research partnership has produced over ten peer-reviewed publications on quantified decision-making. A consistent finding: the structure of relationships between signals and outcomes carries predictive information that the signals alone do not. The context graph is the production embodiment of that finding. Graph memory is how we make causal structure queryable at the speed agents need.

Frequently Asked Questions