Compare

Agent memory solutions differ in where memories live, how they’re shared, and what you have to run.

Landscape #

Local-only #

The simplest options keep memories on your machine. Claude Code, Windsurf, and Cursor write Markdown files scoped to a single client – no setup, but no search and no sharing. claude-mem and claude-memory go further with SQLite session recording, giving you tool-call history across sessions. Obsidian MCP and Nexus use an Obsidian vault as the backing store, which gives you a readable graph of linked notes but requires Obsidian running as a bridge.

QMD takes the local approach further. It runs BM25 keyword search, vector search, and LLM reranking across your markdown files – all locally, using small GGUF models (~2GB). It has an MCP server, so any client can search your notes. If your markdown lives on a NAS or a synced folder, multiple machines can search the same files. That gets you surprisingly far without a database. The trade-off is concurrency – two agents writing to the same file at the same time is where file-based storage gets uncomfortable. But for a single user searching their own notes from different machines, it works well.

All of these hit the same wall eventually: file-based storage wasn’t designed for concurrent writes from multiple agents. Sharing via sync or NAS works for reads, less so when multiple clients are storing memories at the same time.

LLM-powered #

Mem0, Cognee, and Agent Zero use an LLM to extract and organise memories automatically. You don’t call store_memory – the LLM decides what to keep. Mem0 offers a managed cloud platform or a self-hosted version with Qdrant and Postgres, plus optional Neo4j for a knowledge graph. Cognee builds entity-relationship graphs from unstructured data with an LLM pipeline on every ingestion step. Agent Zero bakes memory into its own agent framework with FAISS for local vector search.

The trade-off across all three: you need an LLM running in the memory pipeline, not just for chat.

Database-backed (no LLM) #

MuninnDB is a single Go binary with cognitive scoring (ACT-R decay, Bayesian confidence) and sub-20ms queries. It runs its own embedded storage.

Ogham MCP takes a different route to the same problem. Instead of a dedicated binary, it pushes cognitive scoring, graph traversal, and hybrid search into PostgreSQL – stored procedures, recursive CTEs, and pgvector indexes do the work that would otherwise need a standalone application. Any Postgres instance becomes the memory engine: Supabase, Neon, a VPS, a machine under your desk.

Ogham vs Mem0 vs Cognee vs Agent Zero #

Four approaches to the same problem, different trade-offs on infrastructure and where your data lives.

Mem0 extracts and deduplicates memories using an LLM, with optional knowledge graphs via Neo4j. There’s a managed cloud platform and a self-hosted open-source version. The cloud handles infrastructure for you; self-hosting means running an API server with Qdrant and Postgres. Free tier: 10,000 memories, 1,000 retrieval calls per month.

Cognee builds knowledge graphs from your data – an LLM pipeline extracts entities and relationships, then refines the graph over time. An LLM runs on every ingestion step. Self-hosting recommends 32B+ models. The free tier covers basic workflows. $35/month gets you 1,000 documents, 10,000 API calls, and hosted infrastructure.

Agent Zero bakes memory into its own agent framework. It extracts conversation fragments and problem-solving patterns via LLM, stores them in four memory areas, and uses FAISS for local vector search. The catch: it only works inside Agent Zero, and memories live in local project directories.

Ogham MCP skips the LLM for memory processing entirely. It embeds and indexes what you give it, ranks results with cognitive scoring on top of hybrid search, and discovers relationships by embedding similarity. Everything runs as stored procedures in PostgreSQL – no extra services.

Why PostgreSQL #

Postgres has been around for over 30 years. OpenAI, Anthropic, Supabase, Neon – they all run Postgres. It’s not a bet on something unproven.

The early LLM wave sent everyone scrambling to specialized vector databases. Reasonable at the time. But those setups mean syncing data between two systems, and sync means drift. Delete a memory in your main database but forget to remove the embedding, and your AI starts referencing things that no longer exist. With Postgres and pgvector, your embeddings live next to your data in one ACID-compliant database. Nothing gets out of sync.

All the heavy lifting happens inside that database. Scoring, search, graph traversal, relationship discovery – stored procedures and recursive CTEs, not a separate service. The MCP server calls those functions and passes back results. Hybrid search (semantic + keyword + relational filters) runs in a single SQL query instead of glue code stitching three services together.

Row-Level Security applies to your AI memories the same way it protects your app data. One policy, one place.

So the database is the only thing you need to keep running. Where you put it is your call:

• Supabase or Neon free tier if you don’t want to manage anything
• Hetzner or DigitalOcean if you want a 5-10 dollar box you control
• Your existing Postgres on AWS RDS, Azure, or GCP if you’re already running one
• A machine under your desk if you don’t want anything leaving your network

Pair the last option with Ollama for local embeddings and nothing touches the internet at all.

Embeddings come from OpenAI, Mistral, Voyage AI, or Ollama. Swap providers with a config change and re-embed.

The trade-off is real: you need a PostgreSQL instance and an embedding provider, where local-only solutions need neither. But the database is shared from day one. Point a new machine at the same Postgres instance and it just works – no file sync, no export/import.