mem0 vs supermemory: an append-only memory layer next to a context engine with connectors

Two different ideas about what a memory layer holds

mem0 and supermemory both position themselves as the memory layer between an application and a model, and both are TypeScript projects that also publish Python packages, but they disagree about what memory is for.

mem0 narrows memory to three named scopes: user memory, session memory and agent memory. What makes it interesting is the extraction algorithm it introduced in April 2026. A single-pass ADD-only extraction makes one LLM call and stores what it finds, with no UPDATE step and no DELETE step. Memories accumulate and nothing is overwritten. On top of that sit agent-generated facts stored with equal weight, entity linking so entities extracted from different conversations are embedded and tied together, retrieval that scores semantic, BM25 keyword and entity matches in parallel and fuses them, and temporal reasoning that ranks the dated instance that answers a question about current state, a past event or an upcoming plan.

supermemory starts from a wider product surface and one storage idea. Its README lists a single memory structure and ontology, with memory that extracts facts from conversations and handles knowledge updates, contradictions and automatic forgetting. On top of that it keeps user profiles of stable facts plus recent activity, reachable in one call. The hybrid search returns knowledge-base documents and personalized context in the same query. Connectors auto-sync Google Drive, Gmail, Notion, OneDrive and GitHub through real-time webhooks. Extractors handle PDFs, images through OCR, video through transcription, and code with AST-aware chunking.

So the fork is clear. mem0 is a narrow store of facts about people and conversations with a fast, predictable write path. supermemory is a context layer that mixes documents, media and personal facts in one place and takes responsibility for deciding what stays true.

Append-only writes against facts that expire

The single most consequential difference between the two is what happens when a stored fact stops being true.

mem0's April 2026 algorithm extracts with one LLM call and does not update or delete. That has real virtues: extraction cost tracks conversation volume rather than history size, the write path is predictable, and nothing silently rewrites what an agent was told. It also has a real cost. A user who changes their job title, a project that ships, a preference that reverses: the old fact stays in the store, and the retrieval layer has to decide which of several similar memories answers the question. Our analysis of mem0 puts frequent updates and deletions on the list of reasons to skip it, and that judgement comes straight from the ADD-only design. The same analysis also puts fully offline operation with no external LLM calls out of reach, since extraction is itself a model call.

supermemory takes the opposite decision. Its README lists knowledge updates, contradictions and automatic forgetting as features of the memory system, which means the engine decides when an old fact is superseded and when it should be dropped. That is convenient for the person using the product, because the store stays current without application code doing the cleanup. It is also a delegation of judgement to a component you do not control line by line. Where mem0 hands you a small set of primitives and the responsibility that comes with them, supermemory hands you a store that maintains itself and a set of policies whose edge cases you will discover in production rather than in a diff.

Neither is right in the abstract. The question is whether your product wants to own the correction logic.

Getting mem0 and supermemory running

mem0's shortest path is a package install. The Python package is installed with pip install mem0ai and the Node package with npm install mem0ai. The hybrid BM25 keyword matching and entity extraction need extra dependencies, which the README gives as pip install mem0ai[nlp] followed by python -m spacy download en_core_web_sm. There is also a command line route aimed at agents: install the CLI with npm install -g @mem0/cli or pip install mem0-cli, run mem0 init --agent --agent-caller claude-code to mint a working API key, then mem0 add and mem0 search. A human owner can claim the account later with mem0 init --email and keep the same key and the same memories. Running it yourself is a server stack: cd server && make bootstrap starts the stack, creates an admin and issues the first key, and cd server && docker compose up -d brings up the same stack with a dashboard on port 3000. Self-hosted auth is on by default, with ADMIN_API_KEY and an AUTH_DISABLED escape for local development only.

supermemory has two entry points, and both are worth reading carefully. The first is the hosted MCP server at https://mcp.supermemory.ai/mcp, configured as a URL in your client's server list. It exposes three tools: memory to save or forget information, recall to search memories and return the profile summary, and context to inject the full profile into a conversation. The second is the local install, one binary with zero configuration: curl -fsSL https://supermemory.ai/install | bash. That script brings down the binary and can point it at any model, including running fully offline with Ollama. There are also open source plugins for Claude Code, Cursor, Codex, OpenCode, OpenClaw and Hermes.

The setup burden sits in different places. mem0 asks you to assemble a server and think about keys. supermemory asks you to decide whether a shell script from the internet and a remote endpoint are acceptable in your environment.

What running each one in production involves

mem0 gives you three deployment shapes, and the README is explicit that they are different products: the library for testing and prototyping, the self-hosted server for teams on their own infrastructure, and the cloud platform for production without operations. That means three behaviours to test rather than one. Upgrades matter too, because the project publishes a migration guide from the open-source v2 line to v3, so an adoption that starts on one side of that boundary can end up needing a data migration.

The cost side of mem0 is the extraction call. One LLM call per extraction means your inference bill follows conversation volume, and the published figures put retrieval latency p50 in the sub-second to low-second range with a top_200 retrieval budget on the managed platform. Those numbers describe the managed service, and the README says so, including that the open-source SDK does not contain the proprietary optimizations behind them. Anyone running the open-source path should expect directionally similar behaviour and different numbers.

supermemory puts the production question in a different place. The hosted MCP endpoint sends your data to a remote service, and running your own copy is a separate deployment on your own hardware. On top of that, the connectors are live integrations rather than files you import: to auto-sync Google Drive, Gmail, Notion, OneDrive and GitHub with real-time webhooks, you hold long-lived credentials for each of those services, and rotating and scoping those tokens becomes part of your operational work. The project publishes its newest server tags as server-v0.0.8 and server-v0.0.7, both on a 0.0.x line, which is the detail to weigh before you make this a dependency of a service you have to keep running.

Where each one falls short

mem0 falls short in three specific places. The ADD-only algorithm means corrections and deletions are not part of the write path, so a product whose facts change often needs its own layer on top. Extraction depends on an LLM, which rules out a deployment that must make no external model calls. And the headline numbers come from the managed platform rather than the open-source SDK, which the README itself states, so a benchmark table is not a prediction of what your deployment will do.

supermemory falls short in a different set of places. Its newest server release tags are still on a 0.0.x line, so there is no stable server version to pin a production dependency to, and a team that needs a service with a supportable release line has to decide for itself what to anchor on. The local install asks you to pipe a remote script into a shell, and our analysis of supermemory names that as a reason to stop: a security policy that forbids it rules out the local path entirely. The MCP endpoint is hosted, so data reaches the vendor unless you run your own copy. And its benchmark position, first place on LongMemEval, LoCoMem and ConvoMem, with the recall and context-reduction figures in its README, is published by the project itself.

The tension is worth naming plainly: mem0's README publishes a table claiming 92.5 on LoCoMo and 94.4 on LongMemEval, and supermemory's README claims the top spot on LoCoMo and LongMemEval. Both cannot be describing the same configuration. mem0 open-sourced its evaluation framework so the numbers can be reproduced, which is the more useful starting point for a reader deciding between them.

Licence, maintenance and the choice by scenario

The licences differ in name but not in effect. mem0 is Apache-2.0 and supermemory is MIT. Both permit commercial use, modification and distribution inside a closed-source product without any obligation to publish your changes. The practical differences are narrow: Apache-2.0 carries an express patent grant and a patent-retaliation provision that MIT does not have, and MIT is the shorter document. For a company shipping a memory service to customers that is a small but real difference in the paperwork you keep on file.

Both projects are current. mem0's last push was on 2026-10-19 and supermemory's was on 2026-10-18. Their release shapes are different, though. mem0 published v2.0.19 at the end of August 2026 alongside separate plugin packages, so the core library and the integrations move on their own tracks. supermemory's newest tags are server-v0.0.8 and server-v0.0.7, which says the server is the part still finding its shape.

Pick by situation rather than by feature count. One person who wants their coding assistant to remember preferences across conversations gets the shortest path from supermemory's plugin and MCP server. A team running an assistant in production on its own infrastructure, with per-user memory and issued API keys, gets a clearer and more conventional service from mem0's self-hosted server and library. A product that needs documents and personal facts in one query, with the documents already sitting in Drive, Gmail or Notion, is what supermemory was built for. A product whose memory must be auditable and whose facts change often fits mem0, because the store stays a small set of primitives you can reason about.

Bottom line

Choose mem0 when memory is a small, auditable layer you want to own end to end; choose supermemory when the product needs documents, connectors and a hosted context surface as much as it needs chat history. Before committing, run the same evaluation on your own data, because the headline benchmark numbers in both projects come from tables their own authors published, and mem0 states that its figures describe the managed platform rather than the open-source SDK.

Sources

1. mem0ai/mem0 repository
2. mem0ai/mem0 README
3. supermemoryai/supermemory repository
4. supermemoryai/supermemory README