The real question: what stores the memories
Search for MCP memory server storage and you get directories, hobby repos, and npm packages that all stop at the same place: the tool definitions. Remember, recall, forget. The protocol side is the easy half. The hard half is what happens after remember fires: where the memory lives, how it is indexed, how duplicates are caught, and what survives a restart.
An agent memory MCP server has to answer several retrieval shapes at once. A user paraphrases an old preference, quotes an exact error fragment, asks about last month's project, or expects superseded facts to stay buried. Storage that only does nearest neighbors, or only does exact match, will miss one of those shapes.
The four storage options, honestly
| Backend | What you get | What it costs you |
|---|---|---|
| JSON file (reference MCP memory server) | Zero setup, human-readable knowledge graph on disk | Fine for toys and personal experiments; recall is literal, and the whole file is your scaling plan |
| Redis | Very fast reads and writes, optional vector indexing | You build recall yourself: eviction policy, dedup, filters, and the transaction story between memories and indexes |
| Hosted memory API | Managed service, no storage decisions to own | Per-call pricing, latency on every remember and recall, and your users' memories on someone else's infrastructure |
| MongrelDB (embedded engine) | Hybrid retrieval, transactions, dedup, encryption, local ownership in one binary | You operate the storage and pick the embedding model; no managed multi-region service |
None of these is universally wrong. A weekend project does not need a database engine. A product that charges money for an agent with memory probably should not store that memory in a JSON file or pay per recall.
How MongrelDB backs an MCP memory server
MongrelDB is an embedded, single-node engine written in Rust. Your MCP server process opens the data directory in process through native bindings, or connects to a local mongreldb-server daemon when several processes need one warm database. There is no cluster to run and no external service to pay.
Inside the engine, six public secondary index kinds resolve through the same RowId space: Bitmap for equality, PGM learned range for numeric and time bounds, FM-index for substring containment, ANN for dense vector candidates, Sparse for lexical retrieval, and MinHash for set-similarity candidates. That is the full retrieval surface an agent memory MCP server needs, behind one store.
| MCP tool behavior | MongrelDB mechanism |
|---|---|
| remember(fact) | One transaction writes the row, its embedding, and every secondary index under the same WAL |
| recall("what did the user mean?") | HNSW dense ANN candidates, optionally fused with sparse and MinHash retrievers via reciprocal-rank fusion |
| recall(exact error text) | FM-index substring containment and sparse term retrieval |
| recall scoped to a user or project | Roaring bitmap filters intersect candidates before ranking |
| recall recent or high-confidence only | PGM learned range index on timestamps and scores |
| avoid storing the same fact twice | MinHash near-duplicate candidates with exact Jaccard verification |
| forget(fact) | Delete committed state; search candidates come from the same committed rows the tool reads back |
Bindings exist for TypeScript, Rust, Python, and PHP, so the MCP server can live in the same language as the rest of your agent stack. The Hermes Agent memory plugin runs this exact shape in production: MongrelDB-backed memory over native Rust FFI or HTTP daemon mode, dense ANN by default, encrypted data directories by default.
Long term memory concentrates private data
An MCP memory server accumulates exactly the data a privacy review worries about: user preferences, relationships, project state, debugging context, and decisions. MongrelDB supports page-level AES-256-GCM encryption for sorted-run pages, WAL frames, result cache, and index checkpoints, and the Hermes plugin creates encrypted data directories by default with a random passphrase in a mode 0600 key file.
Keeping memory local also keeps the trust boundary simple. There is no per-call metering on recall, no vendor retention policy to read, and no outbound request in the memory path unless you put one there.
Where MongrelDB fits, and where it does not
Choose MongrelDB when
- your MCP memory server should own memory locally or inside your own service boundary;
- semantic recall must compose with exact text, metadata, recency, and dedup signals;
- memory writes need transactions, recovery, and optional encryption rather than a sidecar index;
- you want SQL and native bindings over the same store instead of a memory framework plus several databases.
Choose something else when
- the project is a toy and a JSON file genuinely covers it;
- you want a managed vendor API and accept per-call pricing and data residency terms;
- the memory store must be a shared multi-region service for many independent writers;
- your organization has standardized on a hosted memory framework and accepts its storage dependencies.
If the fit section sounds right, the next step is the MongrelDB repository: MIT or Apache-2.0 licensed, one storage root, bindings for the languages MCP servers are actually written in. The field notes cover memory schema and retrieval patterns in more depth.
Sources
MCP memory server storage FAQ
What is the best storage for an MCP memory server?
For experiments, the reference MCP memory server's JSON file is fine. For an agent that must recall user facts, project state, and exact phrases across sessions, use a database with hybrid retrieval: semantic vectors, sparse terms, exact substring matching, metadata filters, and deduplication. MongrelDB provides that shape in one embedded Rust engine.
Can I use Redis as the storage behind an MCP memory server?
Yes, and Redis is fast, but you build the memory layer yourself: vector indexing, eviction policy, deduplication, and the transaction story between memories and their indexes. An embedded engine like MongrelDB ships those pieces together under one WAL and MVCC model.
Does MongrelDB run as an MCP server?
MongrelDB is the storage engine. MongrelDB Viewer, the free open source GUI, exposes a MongrelDB database through an MCP tool surface over stdio or loopback HTTP. You can also wrap the engine bindings or the mongreldb-server daemon in your own MCP server with remember, recall, and forget tools.
How do I give my MCP server long term memory?
Back it with a durable store and expose memory tools over MCP. Each remember call writes a row with its embedding and metadata in one transaction; each recall call runs hybrid scored search; each forget call deletes committed state. MongrelDB supports this loop in TypeScript, Python, Rust, and PHP through native bindings or the local HTTP daemon.
When is a hosted memory API a better fit?
A hosted memory API fits when you want a managed service, do not want to own embedding and storage decisions, and accept per-call pricing and memory data leaving your infrastructure. MongrelDB is the better fit when memory should stay local, embed in the product, or combine several retrieval signals under one engine.