Stop Gluing Three Databases Together for Agent Memory

Open the architecture diagram for almost any production agent-memory setup in 2026 and you will find the same three boxes wired together. A vector database for semantic similarity. A graph database for relationships between entities and events. A relational or document store for state, recency, and the boring-but-essential facts. And between them, the fourth thing nobody draws but everybody maintains: the glue code that writes to all three on every update, keeps them consistent, and stitches their results back together at query time. The glue is not on the diagram because it is embarrassing. It is also where most of the bugs live.

The pushback has gotten loud enough to be a product pitch. A database-layer-for-agents project making the rounds this year leads with exactly this complaint - agent memory "shouldn't require three databases and glue code" - and offers to turn JSON into graph relationships, semantic search, and a queryable schema in one place. Whether or not that specific tool is the answer, the diagnosis is correct, and it is the same diagnosis behind the explosion of memory frameworks: the State of AI Agent Memory work this year counts on the order of twenty frameworks and twenty vector stores, a Cambrian sprawl that exists precisely because nobody wants to hand-assemble the stack themselves. This piece is about why the three-database stack happens, what the glue actually costs, and why memory is better understood as one job with several access patterns than as several databases you reconcile by hand.

How the three-database stack happens

Nobody sets out to run three databases for memory. It accretes, one reasonable decision at a time, and the path is so well-worn it is almost a default.

1. Start with a vector store. The first version of memory is "embed everything, retrieve by similarity," because that is the pattern with the most tutorials and the lowest activation energy. It works until you need to ask a question similarity cannot answer, and it fails as a memory in the specific ways we lay out in why vector embeddings are the wrong default for agent memory.
2. Bolt on a graph for relationships. The agent needs to follow connections - this decision depended on that fact, this entity relates to that one - and similarity has no notion of a relationship, so a graph database goes in next to the vector store. Now you have two systems and two write paths.
3. Add a relational store for state. Recency, supersession, scopes, "which fact is current" - the structured state neither the vector store nor the graph handles cleanly - lands in a third system, usually whatever relational database the team already runs.
4. Write the glue. Every memory write now has to land in all three, stay consistent across them, and every recall has to query several and merge the results into one ranked answer. That merge logic is bespoke, it lives in application code, and it is load-bearing.

Each step was locally rational. The sum is a distributed system that has to be kept consistent by hand, for a workload - one agent remembering things - that did not obviously need three databases.

The glue is where the bugs live

The cost of the three-database stack is not the three databases. Storage is cheap and each one is fine at its job. The cost is the seam between them, and it is paid in the failure modes that are hardest to debug because they live in no single system.

• Consistency drift. A write succeeds in the vector store and fails in the graph, or lands in both but not the relational state. Now your three stores disagree about what the agent knows, and nothing flags it. The agent recalls a fact whose relationships were never recorded, or follows a relationship to a fact that was already superseded in a store the traversal did not check.
• Merge logic that nobody owns. Combining a similarity score from the vector store, a path relevance from the graph, and a recency weight from the relational store into one ranking is a real algorithm, and in the three-database stack it is improvised in application code, tuned by vibes, and re-improvised by the next engineer. It is the most important part of recall quality and the least principled part of the stack.
• Provenance fragmentation. The lineage of a memory - where it came from, what it superseded - is exactly the kind of cross-cutting fact that gets split across the relationship store and the state store and reassembled by glue. When provenance lives in the seam, it is the first thing to break, which undermines the trust decisions that lineage and provenance are supposed to enable.
• Operational surface area. Three systems to provision, monitor, back up, secure, and upgrade, plus the glue service, for a feature that is supposed to be a layer, not a platform. Every one is a place an attacker can write to or a deploy can break.
• Migration lock. Swapping the embedding model means re-embedding the vector store while keeping it consistent with the other two - the kind of migration the glue makes terrifying, so teams avoid it and run on stale embeddings instead.

Three databases is not an architecture, it is three caches of the same memory that you have promised to keep in sync by hand. The promise is the bug.

Memory is one job with several access patterns

The mental model that dissolves the sprawl is to stop thinking of similarity, relationships, and state as three databases and start thinking of them as three access patterns over one memory. The agent's memory is a set of facts, each with content, relationships to other facts, provenance, and recency. "Find memories similar to this," "follow the relationships from this memory," and "what is the current canonical value" are three questions about the same underlying thing. They do not need three systems any more than a relational database needs a separate engine for each kind of index. They need one store that holds facts as first-class records with relationships and state, and exposes similarity, traversal, and structured query as ways in.

This is the direction the serious work is heading. Temporal knowledge graphs fold relationships and recency into one structure. The framing of memory as a dedicated architectural component - not a longer prompt, not a bolted-on index - that recurs across the 2026 literature is, underneath, an argument that memory deserves a purpose-built store rather than an assembly of general-purpose ones. When memory is one component, the merge problem stops being glue code and becomes the store's ranking function, the consistency problem stops existing because there is one write path, and provenance stops fragmenting because it is a property of the record rather than a join across systems. That single ranked recall - similarity plus relationship plus recency, decided in one place - is the contest we describe in why AI memory layers recall the wrong thing, and it is genuinely hard to get right in glue code precisely because the three signals live in three systems.

When the stack is actually justified

To be fair to the three-database setup: it is the right call in one situation, which is when the three stores are serving genuinely different jobs rather than three views of one memory. A vector store doing read-only retrieval over a large external corpus is a different system from your agent's memory and should stay separate - that is the RAG-versus-memory line we draw in is RAG dead for agents, and conflating them is its own mistake. Likewise, an analytics warehouse is not your memory store. The argument here is not "one database for everything." It is narrower and sharper: the agent's memory - the write-back store of what the agent has learned, with relationships, state, and provenance - is one job, and splitting that one job across three databases plus glue is the avoidable sprawl. Keep your corpus retrieval separate; stop shattering your memory.

What consolidating the stack buys you

Collapsing memory into one purpose-built layer is not just less to operate, though it is that. It changes what is possible:

• One write path, no drift. A memory is recorded once, with its relationships, provenance, and state, atomically. The stores cannot disagree because there is one store. Consolidation and the record step become a single transaction rather than a three-way write you hope completes.
• Ranking as a feature, not a script. Similarity, relationship relevance, and recency are combined by the layer's recall function, tuned and tested as a unit, instead of improvised in every application that touches memory.
• Provenance and correction that hold. Because lineage is a property of the record, supersession actually works and you can audit why a memory surfaced - the foundation for trusting, correcting, and forgetting, including the right-to-be-forgotten deletes that a three-store stack makes terrifying.
• A real surface, not a bespoke client. One layer can expose a clean tool interface - over MCP, for instance - so the agent calls "recall" and "record" without knowing or caring which index answered, the surface we compare across implementations in MCP memory servers compared.

The takeaway

The three-database agent-memory stack is an accretion, not a design: a vector store for similarity, a graph for relationships, a relational store for state, and glue code holding the promise that they stay consistent. That promise is where consistency drift, improvised merge logic, fragmented provenance, and a platform's worth of operational surface come from. The reframe is that memory is one job with several access patterns, not several databases - the agent's learned facts, with relationships, state, and provenance, queryable by similarity, traversal, and structured lookup over one store. Keep your external corpus retrieval separate, by all means. But the memory itself wants to be one layer, and the loud complaints about glue code this year are the field figuring that out.

That single layer is what memnode is. It holds memories as first-class records with relationships, provenance, and recency, and runs the whole record, recall, lineage, correction loop over one store - so similarity, relationship traversal, and canonical-truth state are access patterns into the same memory rather than three systems you reconcile by hand. It speaks MCP so an agent uses it as one tool, and it ships hosted when you would rather not run any of the boxes. Delete the glue.