THE BUILD-IT-YOURSELF QUESTION
Just keep memory in something you already control.
Published Updated
Two versions of the same instinct. Write it to files, because files are transparent and agents are good at them. Or put it in your database, because that is where governed state belongs. Both are right that memory needs schema, audit, and control. Both stop short of the work a memory layer actually does. Here is where each one breaks.
Files work until you have more than one user, more than one agent, or two facts that contradict each other. Postgres gives you storage and governance but not entity resolution, contradiction handling or decay. A memory layer earns its cost at roughly the point where you would otherwise write a nightly deduplication job.
| Your situation | What to use |
|---|---|
| One developer, one agent, one project | Markdown files in git |
| One tenant, structured facts you control | Postgres with a schema |
| Retrieval where exact terms are the key | Keyword or file search |
| Users phrase things differently from your source text | Vector search |
| More than one user, or more than one agent, or facts that change | A memory layer |
THE FILESYSTEM QUESTION
Just write to markdown files. You do not need a product.
This is the newest version of the objection, and it is the most credible, so I want to take it seriously rather than wave it away. Since Claude Code and OpenClaw made file-based context normal, a lot of people have landed on the same idea. Keep a MEMORY.md, let the agent read it and edit it, put it in git. The memory is transparent, you can open it in any editor, you can diff it, you can revert it when the agent goes off the rails. Agents are natively good at reading and editing files, because that is what coding models were trained on. For one developer and one agent, this genuinely works.
There is a version of this argument that can be measured instead of debated, so we measured it. We ingested 50,000 documents across five datasets and ran 5,000 queries against them, comparing Tantivy for keyword search against ChromaDB for vector search and scoring both on MRR@10.
Two results matter here. Vector search led on the five-dataset average by 0.6320 to 0.5325, and the entire margin came from a single dataset. On CodeXGLUE, which is natural language translated into code and therefore the purest semantic-gap task in the set, vector search scored 0.9143 against 0.2901. Remove that one dataset and keyword search wins the remaining four, 0.5931 to 0.5614. On SciQ, which is science exam questions where the terminology is the key, keyword search led 0.8145 to 0.6142.
The second result is the cost of getting there. Indexing those 50,000 documents took 2.11 seconds with keyword search and 161.6 seconds with embedding generation, a factor of 76.4. That is 23,650 documents per second against 309.
So the file-based instinct is right about more than people give it credit for. If your agent retrieves over terminology it controls, files and keyword search are both more accurate and roughly seventy times cheaper to index. The full results, method and limitations are here.
What files do not survive is everything that happens after retrieval, and the most instructive case in that benchmark is HotpotQA. Those questions require linking two documents, and vector search would find the document for the first entity and miss the bridge document for the second, because the second was not similar enough to a query that was mostly about the first. The answer was retrievable and the evidence was not. That failure produces a confident, unsupported answer rather than an error, which is the same shape as every other failure in this section.
Independent testing has found configurations where a memory layer performs worse than doing nothing clever at all. Published comparisons have measured Mem0 and Zep against simply passing the whole conversation history into the prompt, and found the memory systems costing materially more while recalling fewer facts. In our experience that holds below a few thousand tokens of history, where passing everything is both cheaper and more accurate than any extraction pipeline, including ours. Any vendor asking you to buy a memory layer should be able to tell you the conditions under which their own product is the wrong choice.
Files are a great interface. They are a weak system once you leave single-player. The cracks show up on exactly the things production needs, and they show up fast. Two agents writing the same file at once. Retrieval when the file is no longer a file but ten thousand users worth of history, where grep does not rank and the right memory is somewhere in the middle. Entity resolution across all those users. Two notes that contradict each other, with nothing deciding which one wins. Decay, so old facts stop driving new actions. Access control, so a junior analyst session does not read what was written during a CFO session.
The tell is what people build the moment files stop scaling. One developer who shipped a file-based memory for an agent fleet immediately had to add a daily job to dedup, synthesise, and promote the knowledge across files, which is the memory layer, rebuilt by hand, one cron job at a time.
So I am happy to concede the 80%. If you have one agent and one user, write to a file. The 20% that files do not cover, more than one user, more than one agent, more than one session that contradicts the last, is not a rounding error. It is the part that decides whether the thing works in production, and it is the part Synap takes care of so you do not rebuild a database badly.
THE DATABASE QUESTION
It is just a database problem. The incumbents win.
This is the sharpest version of the skeptic case, usually made by people who have run real data infrastructure, and they are mostly right. Memory that affects real decisions should have schema, access control, audit, retention, and lineage. Databases have spent decades earning that scar tissue. If an agent can write back to its own memory, every interaction is a state change in a system that future decisions depend on, and that deserves to be governed like a database, not treated like a scratchpad.
The specific thing a database does not give you is isolation inside a retrieval path. The common pattern is one shared vector store with a tenant identifier in the query filter, which is a WHERE clause wearing a security badge. When that filter is dropped or malformed, an ordinary application returns an error and someone gets paged. A retrieval path returns a fluent, confident answer assembled from another customer's data, and nothing in your monitoring fires, because from the system's point of view nothing failed.
The second is write governance. If an agent can write to its own memory, every interaction is a state change that later decisions depend on. A database will store two contradictory facts without complaint and return both at retrieval time with equal confidence. Deciding which one wins, and when the older one should stop being retrieved at all, is a memory operation rather than a storage operation, and it is the operation that decides whether the agent behaves consistently three weeks from now.
I agree with all of that. It is an argument for a real memory layer, not against one. The critique is really saying stop dumping JSON blobs into a vector store with no schema and no audit trail and calling it memory. That is a specification, and it is one we meet. A bare database gives you storage and governance primitives. It does not give you the memory operations on top, the entity resolution, the temporal reasoning, the relevance ranking, the conscious forgetting, or the write-time checks that decide whether the agent should remember something at all.
So the reframe is simple. They are right that memory is a database problem. They are wrong that your existing database, on its own, solves it. Synap is the layer that adds the operations and the agent-write governance the raw database was never built to do.
THE COST QUESTION
Fine. What does each option actually cost?
Most comparisons in this category report accuracy and stop, which is the wrong half of the decision, because a memory layer has two cost lines and vendors normally quote one.
The first is what you pay the vendor. The second is what the memory layer does to your token bill, and it moves in both directions. Extraction-based systems make two to three model calls to store a single memory, which at a hundred thousand memories a month puts the extraction bill somewhere between one and three thousand dollars before anything has been retrieved. Naive consolidation is worse, because comparing every memory against every other is quadratic, and a ten-thousand-memory store consolidated that way runs into thousands of dollars of inference per pass. Against that, a memory layer that works removes conversation history from the prompt, and that is where the saving comes from.
There is a third cost almost nobody discloses. Background extraction writes to the same prompt prefix your cache depends on, so a memory layer that writes mid-conversation can invalidate the cache and raise your bill while appearing to lower it. Ask any vendor, ourselves included, for cache hit rates measured before and after.
The economics are set out formally in our paper on Agentic Context Management. Naive accumulation grows token cost quadratically, validated compaction grows it linearly, and the crossover arrives earlier than most teams expect.
THE EVALUATION QUESTION
How do I decide without a six-month pilot?
The structural problem with evaluating a memory layer is that the value compounds over months while the evaluation budget is measured in hours. Every vendor in this category has that problem and none of us have solved it honestly. This is the shortest test we know that produces a real signal.
Take fifty turns of your own production conversation history rather than a benchmark. Run three configurations against the same set of questions: the full history passed into the prompt, your files or database as they stand today, and the memory layer. Measure three things and nothing else. Task success, judged by someone who knows your domain rather than by a model from the same family as your answerer. Total cost per completed task including retries, rather than cost per call. And end-to-end added latency per turn, rather than per operation.
If the memory layer does not win on at least two of those three at your current conversation length, you do not need one yet. Come back when conversations get longer or user count grows, because those are the two variables that move the answer.
Our harness is open at github.com/maximem-ai/memory_and_context_eval_harness and it runs against any vendor, including the ones we lose to. The reproduction results, including where published vendor numbers do not survive an independent harness, are in the state of AI memory post.
Questions people ask before deciding
Yes, for one developer and one agent. Files are transparent, diffable and revertible, and coding models are natively good at them. They break on concurrency, on ranking once history grows past what grep can sort, on entity resolution across users, on contradictions, on decay and on access control.
Not necessarily. In our benchmark, keyword search won the average across the remaining four datasets once the natural-language-to-code case was removed, and indexed 76.4 times faster. You need vectors when your users phrase things differently from your source text.
Retrieval is one operation inside a memory layer. The others are deciding what to store, resolving the same entity across sessions, ranking contradictory facts, letting old facts decay, and enforcing who can read what. A retrieval system does the first thing well and none of the rest.
It depends on whether the system extracts on write. Extraction-based systems make two to three model calls per stored memory, which at scale is a material line item before retrieval. Ask for extraction cost, retrieval cost, added context tokens and cache hit rate separately, because a single blended number hides all four.
The threshold is not user count, it is the first time two sessions write facts that contradict each other, or the first time one user must not see what another wrote. Both can happen at two users.
For storage, audit and retention, yes, and you should. What Postgres does not do is entity resolution, contradiction ranking, decay, or write-time relevance checks. It also does not enforce tenant isolation inside a retrieval path, which is the failure described above.
Run the five-day test in the section above. Three configurations, your own conversation history, three metrics.
This is a fair question to ask everyone, ourselves included, and it is fair because it has already happened. Zep discontinued its self-hosted Community Edition in April 2025, leaving the repository open under Apache 2.0 but unmaintained. Our own answer is published on the Synap security page, and it is the one to hold us to. You set retention per data type rather than having us age your data out on a schedule of our choosing, raw input payloads are deleted after 15 days, a full deletion completes within 20 business days, our DPA obligates deletion or return of your data when the contract ends, and a self-hosted deployment, including a fully air-gapped one, exists today, where your data never leaves your own infrastructure and we hold no copy of it to delete.
When files and databases stop scaling, this is what they become.