Building a context graph on the wrong database is a tax you pay forever.
A context graph is the living web an agent reasons over: history, tool outputs, entity relationships, task dependencies, provenance, and long-term memory — all connected, constantly evolving, scoped to a run, a user, or a tenant. The mainstream data stores were designed for none of that.
For two decades we've built data systems around three assumptions: data is mostly flat, mostly long-lived, and mostly shared. Agent context breaks all three.
It's relational by nature — every fact connects to a source, a time, a user, a tool call. It's ephemeral — most of what an agent needs is relevant for the next few seconds. And it's private per agent — what one agent learned about Maya should not leak into another agent reasoning about Sam.
Plug those requirements into a vector DB, a relational DB, a document DB, or a centralized graph DB, and you'll spend the rest of the year working around the mismatch.
Where each option breaks
Each of these is the right answer to a different question. None of them is the right answer to "give me an agent context graph."
Vector stores
Vector stores find what's similar. They cannot find what's connected. A context graph is defined by its edges — provenance, dependency, ownership, temporal order — and vectors collapse all of that into a single similarity score.
- •No concept of an edge — only cosine distance.
- •No traversal: you cannot ask 'what depends on X?'
- •Re-ranking is bolted on; structure is invisible.
Relational databases
Postgres and friends are excellent at flat, well-typed rows. They fall apart the moment your data is a mesh. Every 'who depends on whom' question becomes a recursive CTE that scales with the number of hops, not the size of the answer.
- •Recursive JOINs slow to a crawl past 2–3 hops.
- •Schema migrations become political the moment relationships grow.
- •Provenance edges turn into FK tables nobody wants to maintain.
Document stores
MongoDB's $graphLookup fakes graph traversal on top of documents. It works for narrow, hierarchical fan-out and falls over on dense, cross-linked meshes — exactly the shape an agent's memory takes.
- •$graphLookup fan-out is exponential on cyclic data.
- •Atomic multi-entity updates are not first-class.
- •You end up shipping graph logic into application code.
Neo4j
Real edges. Real Cypher. Wrong deployment model. Neo4j was engineered for one large, centralized, analytical graph that lives for years. An agent wants the opposite: thousands of tiny graphs that live for seconds.
- •17-second cold start, ~3.5 GB JVM footprint per instance.
- •Clustering is heavyweight; per-agent isolation is prohibitive.
- •Cannot meaningfully run at the edge or inside a function call.
An agent's context graph is small, numerous, ephemeral, shared, and everywhere. Every other option is generic, heavy, singular, or structureless.