MemoMind: a local memory layer for Claude Code, built on PostgreSQL and pgvector

The problem MemoMind picks, and the one it deliberately leaves alone

Claude Code starts each session with no recollection of the last one. The README frames this as amnesia rather than a capability gap, and that framing is the project's whole argument: the models are good enough, the missing piece is continuity. MemoMind targets the machine-facing half of that continuity. It stores preferences, decisions and project context so the agent can retrieve them later without you re-explaining your stack every morning.

The README is explicit that this is only half the problem. It separates memory for the AI (what it knows) from memory for the human (what you can browse and search), and states that MemoMind handles the AI side while a companion project called Recall handles conversation history management. That split is worth taking seriously because it tells you what MemoMind is not: it is not a searchable archive you will enjoy reading. The dashboard screenshots show a memory stream, a graph view, a timeline and type filters, so there is a UI, but the design centre is retrieval by the agent, not browsing by you.

The audience is narrow and specific. You need to be running Claude Code, you need to be willing to run PostgreSQL locally, and you need conversations worth remembering. A developer who spends two hours a week with an agent will not accumulate enough memory for retrieval to beat simply restating the context.

How MemoMind actually works: retain, recall, reflect over Postgres and pgvector

The mechanism visible in the README is a three-verb loop. The agent calls retain to store a fact, recall to fetch relevant memories, and reflect to synthesise across stored memories. MemoMind exposes these over MCP using stdio, which is why the README badges the protocol as MCP (stdio) and why installation is framed as wiring a server into Claude Code rather than importing a library.

Storage is PostgreSQL with the pgvector extension. That choice drives most of the project's behaviour. Vector similarity search handles semantic recall, and on top of it the README describes a four-way hybrid search that returns only relevant memories instead of loading a whole file into context. A knowledge graph layer sits alongside the vectors, with named entities and links between them, and the README describes temporal relationships and entity linking as what separates this from append-only notes.

The data flow for a single fact looks like this in the README's own example: you say you are migrating from Express to FastAPI, the agent internally calls retain with a short summary of that decision, and a week later a new session calls recall on the project tech stack and gets the decision back. The extraction is automatic, which the README contrasts against CLAUDE.md where you write the rules yourself. reflect is the piece with no equivalent in a markdown file: it synthesises insights across many stored memories rather than returning the nearest ones.

One structural detail matters for planning. The README's production numbers include a daily LLM cost under $0.01, which only makes sense if something is calling a model. Combined with automatic extraction, that implies retain is not a pure database write. The README does not spell out which model or where it runs, so if you need fully offline behaviour you should confirm that before committing.

Getting it running: MCP registration plus a Postgres instance you maintain

The README's quick start points at Windows, Linux and WSL2, and the badges name the two hard dependencies: PostgreSQL with pgvector, and CUDA for GPU acceleration. The MCP transport is stdio, so the practical setup is a server entry in your Claude Code MCP configuration rather than a service you call over HTTP.

Two config keys are visible in the material. The storage layer is PostgreSQL plus pgvector, so a connection string pointing at a database with the vector extension enabled is the first thing to get right. The GPU path is CUDA, which means an NVIDIA driver and toolkit on the machine running the server. The README does not reproduce the exact JSON block for the MCP server entry, and it does not list the environment variable names for the database URL. That is a real gap: you will be reading the repository rather than the README to complete the wiring.

What the README does not describe is a migration or schema initialisation step. Since the storage is a relational database with an extension, there has to be a way to create the tables and enable pgvector, but the quick start as given does not show it. Treat that as the first thing to look for in the repo, because a half-initialised database will fail at retain time rather than at startup.

If you are on macOS with Apple silicon, the CUDA badge is a warning sign. The README lists Windows, Linux and WSL2 as supported platforms and does not mention macOS. The system may run without GPU acceleration, but the documentation does not say so, and I cannot confirm it from the material.

The scaling numbers in the README are also the cost estimate

The README reports a production instance with 50,100 or more memory nodes, 2,900,000 or more knowledge links, 4,600 or more named entities, and a database around 500 MB, spanning 2017 to the present. It also reports keyword search at 20 to 33ms and semantic recall at 235 to 430ms.

Read those two latency figures together and you get the honest picture. Keyword search is fast because it is an index lookup. Semantic recall is roughly ten times slower because it is a vector search, and possibly a hybrid one. If your agent calls recall on every turn, you are adding a quarter to nearly half a second per call before the model starts generating. That is tolerable for a session-start context load and painful inside a tight loop. The README does not say how often recall is invoked, so the decision is yours.

The 2.9 million knowledge links against 50,100 nodes is the more interesting number. That ratio suggests the graph is dense, roughly 58 links per node, which is consistent with entity linking on imported conversation history rather than hand-curated facts. Dense graphs make reflect-style traversal more expensive over time. The README gives no query plan or index detail for the graph layer, so how that scales past the reported size is unverified.

The imported data is worth noting for a different reason: 541 AI chats, 5,500 or more life events covering 2,400 or more days, and 13,400 or more knowledge vault documents. That is a personal corpus, not a team one. The project's design centre is one person's accumulated digital life, and the README's framing around a digital twin confirms it.

Where MemoMind is the wrong tool

The clearest limitation is stated by the project itself. The README says CLAUDE.md and MemoMind are complementary, not competing, and gives the split: static project rules like indentation style belong in CLAUDE.md, dynamic knowledge that accumulates belongs in MemoMind. If your needs are entirely static, adding Postgres, pgvector and a CUDA dependency to store a style guide is a poor trade.

The second limitation is operational. MemoMind is a database-backed service, not a file. It needs PostgreSQL running, the pgvector extension installed, a schema, and a backup story. The README does not describe backup, export or restore. That silence matters more than usual here, because the README's own pitch is that the memory is portable and ready to migrate when a better system comes along. Portability is a claim about data you can extract. With a knowledge graph and 2.9 million links, the export path is the thing that determines whether that claim holds, and the material does not show it.

The third is the licence. The README carries an MIT badge and links to a LICENSE file, but the repository metadata supplied lists the license as unknown. Those two facts conflict, and until the LICENSE file is checked, you do not know the terms. For a local tool that never leaves your machine this may not matter. For anything you intend to redistribute or embed in a product, it does.

Finally, the project has no releases retrieved. Installation is from the default branch, master. There is no tagged version to pin, which makes upgrades a matter of pulling whatever is current.

The alternative: markdown memory files, and what the difference costs

The obvious alternative is what Claude Code ships with: CLAUDE.md and MEMORY.md. The README lays out the difference in its own comparison table. Markdown files are plain text, you write the extraction rules yourself, and retrieval means loading the file into context every time. MemoMind stores in Postgres with pgvector and a graph, extracts facts automatically, and retrieves through hybrid search so only relevant memories enter the context window.

The trade is not close in either direction. Markdown files have no dependencies, no schema, no daemon and no latency floor. You can read them in any editor and diff them in git. MemoMind buys you selective retrieval and cross-session synthesis, and charges you a database, a GPU dependency, and 235 to 430ms per semantic recall. The README's own estimate is that markdown breaks down around 200 lines because of context bloat. That figure is the decision boundary: below it, use the files; above it, the file approach starts costing you tokens on every turn, and MemoMind's selective retrieval starts paying for its complexity.

A second alternative is the companion project the README names, Recall, which handles conversation history for the human. If what you actually want is to find what you discussed last Tuesday, Recall is the tool described for that job, and MemoMind is aimed at a different question. The README recommends using both together, which is a reasonable reading of the split but also means adopting MemoMind alone leaves half the stated problem unsolved.

Maintenance, upgrades and what the licence status means in practice

There are no retrieved releases, so there is no version number to pin and no changelog to read before upgrading. On a master-branch install, an upgrade means pulling new code and hoping the schema still matches. Because storage is relational, a schema change on the project's side can require a migration on yours, and the material does not describe a migration tool. Before you put real memory in it, find out how the project handles schema changes, or accept that you may be rebuilding the database.

The ongoing costs are three: PostgreSQL has to stay running and backed up, the CUDA stack has to stay compatible with your driver, and the retain path incurs an LLM cost the README puts under $0.01 per day at its reported volume. That last figure is small, but it is a recurring external call unless you have confirmed the extraction model runs locally, which the README does not state.

On licensing, the README shows an MIT badge and links to a LICENSE file, while the repository metadata supplied here records the license as unknown. I am not giving legal advice; the practical point is narrower. Before you depend on MemoMind, open the LICENSE file and read it. If it is MIT, the usual permissions and the usual warranty disclaimer apply, and the warranty disclaimer is the part that matters for a tool holding nine years of personal history with no documented export path.

Editorial conclusion

Adopt MemoMind if you already run PostgreSQL, you want agent memory to stay on your machine, and you accept that the retain and reflect paths call an LLM. Do not adopt it if you want a single binary with no database, or if you need a licence you can verify before shipping. Verify three things first: that the LICENSE file actually contains MIT text, that pgvector is installed in the target database, and whether the recall latency the README reports (235 to 430ms for semantic search) is acceptable inside your agent's loop.

Official sources

1. 24kchengYe/MemoMind on GitHub
2. Issues
3. README