
Membase vs Supermemory: Which Memory Layer Should You Use in 2026?
Disclosure: Membase is our product. We wrote this comparison to be useful to developers choosing between the two, so we say plainly where Supermemory is the better fit. Supermemory’s features, pricing and licensing were checked on its pricing page, docs and GitHub in October 2026; see “How we compared” at the end.
Quick links: Get a free Membase API key · Python SDK · MCP server · Docs · GitHub
TL;DR
Both are hosted memory layers for AI agents with SDKs, a REST API and a hosted MCP server, and both can run on your own machine. They differ in what they optimize for:
- Supermemory gives your application a memory graph per user. One API key reaches many namespaces (user_alex, user_jordan), facts update and expire automatically, user profiles are built for you, and connectors sync Google Drive, Gmail, Notion, OneDrive and GitHub. Usage is billed from monthly credits.
- Membase gives one memory to your agents and the AI tools around them: Claude Code, Cursor, Codex and ChatGPT read the same memory as your code. Apps connected by consent are read-only by default, and every result comes back with the memory and source it was learned from. Free in beta.
Choose Supermemory for a multi-tenant app that needs per-user memory behind one key, facts that update themselves, built-in connectors, or compliance paperwork today. Choose Membase when your agents and your team’s AI tools should share one memory, each app should only read what you approve, and you want to start free without modeling usage meters.
Membase vs Supermemory at a glance
| Membase | Supermemory | |
|---|---|---|
| Best for | One memory shared by your agents and your AI tools | Per-user memory and profiles inside a multi-tenant app |
| What gets stored | Documents and notes, learned into timestamped episodes and topic trees, each tied to its source | Documents (kept as chunks for RAG) plus facts extracted into a memory graph |
| How memory is scoped | Per account; a “container” is a topic, such as Project decisions | Namespaces (formerly container tags), such as user_alex or org:acme:team:growth, each with its own index |
| Changing facts | Episodes keep who said what and when; no automatic overwrite | Graph relations: updates supersede old facts, extends enrich them, derives infers new ones; expired facts are forgotten |
| User profiles | Profile (get_profile) | Built-in static and dynamic profiles |
| Access control | Keys per memory: level (Read, Read & write, Full), reach and expiry; MCP apps read-only by consent | API keys scoped to namespaces, optionally read-only; per-namespace member permissions |
| MCP | Hosted: api.app.membase.com/mcp-http; local: membase --local mcp | Hosted: mcp.supermemory.ai/mcp (OAuth, spaces) |
| AI apps it connects to | Claude Code, Cursor, Codex, ChatGPT, Claude, Grok; Chrome extension for 6 chat apps | Plugins for Claude Code, Cursor, Codex, OpenCode, Muse Code and Hermes; any MCP client |
| Connectors | Uploaded files, folders, Notion, chat captures from the extension | Google Drive, Gmail, Notion, OneDrive, GitHub, Granola, web crawler, S3 |
| Self-hosting | Local mode (unibaseio-membase[local]); compiled engine | Supermemory local: one binary, free up to 10,000 documents; server code not public |
| License | Proprietary; SDKs, CLI and MCP server are public | Repository MIT; self-hosted server binary built from non-public code |
| Pricing | Free in beta · Paid plans coming soon | Free ($5 credits) · Pro $19 · Max $100 · Scale $399 · Enterprise, usage drawn from credits |
| Compliance | Beta; no published certifications yet | SOC 2, HIPAA BAA on Scale and Enterprise, per Supermemory |
| Maturity | Beta, launched 2026 | Established; ~31K GitHub stars |
What each one is
Supermemory is a memory and context engine for AI. You add documents, chats, files or connector items to a namespace; Supermemory keeps chunks for retrieval (its SuperRAG) and, in a second phase it calls dreaming, extracts facts into a temporal memory graph. You search memories and documents together, or load an automatic user profile. It runs as a managed platform or as a self-hosted single binary.
Membase, built by Unibase, is a hosted memory layer that your code and your AI tools share. You add facts, documents, web pages or chat exports to a memory (a “container”); a learning run turns them into timestamped episodes and topic trees. Your agents reach it through the SDK or REST, and Claude Code, Cursor, Codex and ChatGPT reach the same memory through MCP.
6 differences that decide the choice
1. Whose memory it is: your app’s users, or you and your agents
Supermemory is built for an application that stores memory about many end users. One API key writes to and searches any namespace in your organization, and each namespace is an isolated index. Namespaces can be a user, a project, a team or a hierarchy (org:acme:user:john). A request touches one namespace at a time.
Membase treats the account as the tenant. A container is a topic, not an end user. If your product serves many people, each person connects their own Membase account, by OAuth consent over MCP or with their own key. There are no app-wide keys reaching every user’s memory.
What that means for you: if you’re building a consumer or SaaS app with thousands of end users behind your backend, Supermemory’s namespaces fit better today. If you’re building agents for yourself or your team, or a product where users bring and own their memory, Membase fits better.
2. How memory is built and kept current
Supermemory builds a graph of atomic facts. New facts connect to old ones in three ways: an update replaces what was true (“Alex just started at Stripe” supersedes “Alex works at Google”), an extend adds detail, and a derive infers a fact you never stated in one place. Temporary facts expire, contradictions resolve to the newest, and casual chatter is filtered out. By default, related documents are grouped before facts are extracted, so memories can keep forming after a document shows as processed; an instant mode makes them available right away for one extra operation.
Membase reads what you add (notes, documents, chat exports) and narrates it into timestamped episodes that keep who said what, and when, together. Episodes are organized into topic trees inside each container. Membase doesn’t keep a fact graph and doesn’t overwrite older facts automatically; instead, because each episode carries its time and source, the newest statement and its context come back together at search time.
What that means for you: if your app needs “the current truth about this user” maintained for it, Supermemory does that out of the box. If you’d rather see the full context around a statement than a fact the system has already resolved, Membase keeps it.
3. Who can read the memory, and what they can do
Both let several assistants share one memory over MCP. The difference is the default.
Supermemory MCP signs in with OAuth and lets you choose which spaces a client can access. Its tools search, add and forget memories and read documents and profiles. API keys can be scoped to a set of namespaces and made read-only, and organization members can get read or write access per namespace.
Membase connects AI apps through a consent screen, and those apps get read-only access to the memories you tick: they can search them but can’t add, change or delete anything. Agents that need to write get a developer key with its own level (Read, Read & write or Full), reach and expiry. Deleting or forgetting needs a Full-access key and an explicit confirm=true. Revoke one agent without touching the others.
What that means for you: both can be locked down. Membase starts locked and you open it up per agent; with Supermemory you choose scopes as you create keys and connect clients.
4. AI tools and connectors
Supermemory ships plugins for Claude Code, Cursor, Codex, OpenCode, Muse Code and Hermes. The Claude Code plugin loads profile facts at session start, searches before each prompt and captures the conversation after each response, and its coding plugins share one memory per repository. Connectors sync Google Drive, Gmail, Notion, OneDrive, GitHub and Granola in real time, plus a web crawler and S3 (Gmail from the Max plan; S3 and the web crawler on Scale).
Membase connects to Claude Code, Cursor and Codex over MCP, and to ChatGPT, Claude and Grok as apps, so the same memory is there in chat and in code. The Chrome extension saves context from ChatGPT, Claude, Gemini, Grok, DeepSeek and Kimi into it. It reads uploaded files, folders and Notion, and has fewer connectors than Supermemory.
Add Membase to Claude Code in one line:
claude mcp add --transport http membase https://api.app.membase.com/mcp-http \
--header "Authorization: Bearer $MEMBASE_API_KEY"
Watch it in under two minutes: Give Claude Code permanent memory with Membase (MCP).
5. Search and what comes back
Supermemory searches memories, documents or both in one call, with metadata filters inside a namespace and optional related graph edges. Its MCP search returns memory IDs and the IDs of the source documents.
Membase fuses keyword and vector search, then a retrieval step reads the first hits and asks follow-up queries (up to three rounds) before settling. Every result carries the container it came from and its source document. Search takes a query, an optional container and a limit; metadata filters aren’t supported, so put constraints into the query or split memories into containers.
6. Self-hosting, license and maturity
Supermemory local is a single binary with an embedded graph engine and local embeddings, and it runs fully offline with a local model through any OpenAI-compatible endpoint. It’s free within a lite license limit of 10,000 stored documents. The SDKs and other components in its MIT-licensed repository are open source; the server binary is built from a separate, non-public codebase. Connectors and Supermemory MCP are platform-only, and it collects telemetry unless you turn it off. Supermemory is the more established product, with about 31K GitHub stars, and lists SOC 2 and a HIPAA BAA on its Scale plan.
Membase has a local mode: pip install 'unibaseio-membase[local]' runs memory on your machine with OpenAI, Anthropic, Ollama or any OpenAI-compatible model, and membase --local mcp serves it to your AI tools. The engine it installs is compiled and proprietary; the SDKs, CLI and MCP server are public. Membase is in beta, so expect the API to change, and it doesn't publish compliance certifications yet.
The same task in both: add a fact, then search it
Supermemory (TypeScript, from its docs)
import { Supermemory } from "supermemory";
const supermemory = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY });
await supermemory.add("user_alex", { content: "We picked Postgres for the ledger service." });
await supermemory.search("user_alex", { query: "what database is the ledger on?" });
Membase (Python)
from membase import Membase
m = Membase() # reads MEMBASE_API_KEY
m.memories.add("We picked Postgres for the ledger service.", container="Engineering")
m.search("what database is the ledger on?")
The shape is the same. The difference is the scope argument: Supermemory asks which namespace, usually a user; Membase asks which memory, a topic.
Pricing
Supermemory (pricing): every plan includes a monthly credit balance, and calls draw from it at the same rates on every plan. Only unique content is billed.
- Free — Price: $0; Credits included / month: $5
- Pro — Price: $19/mo; Credits included / month: $20; Notes: 3 team seats, unlimited end users
- Max — Price: $100/mo; Credits included / month: $130; Notes: Gmail connector
- Scale — Price: $399/mo; Credits included / month: $600; Notes: PDF extraction, S3 and web crawler connectors, SOC 2, HIPAA BAA, self-hosted option
- Enterprise — Price: Custom; Credits included / month: Committed spend; Notes: Air-gapped self-hosting, SSO, custom contracts
- Memory, plain text → $5 per 1M tokens ingested
- Memory, rich content → $10 per 1M tokens
- SuperRAG, text / rich → $1 / $2 per 1M tokens
- Search → $5 per 1M queries
- Operations (re-ranking, query rewriting and similar) → $100 per 1M operations
Forecasting a month means estimating ingestion, search and operations separately.
Membase: Free in beta · Paid plans coming soon. The free plan includes a chat-turn allowance for the built-in assistant; when it’s used up, your memories stay and you can connect your own model key.
Benchmarks
Both publish results on LoCoMo and LongMemEval. Membase’s core engine reports 93.1% on LoCoMo, 92.6% on LongMemEval_S and 92.2% on DMR, using about 3× fewer tokens than the full history on LoCoMo and 11× fewer on LongMemEval_S (method and results). Supermemory reports first place on LongMemEval, LoCoMo and ConvoMem in its GitHub README, and maintains MemoryBench, an open-source framework for comparing memory providers.
We don’t put the two side by side: each vendor runs its own setup, with different reader models, judges and LongMemEval variants, so the numbers aren’t comparable. Run both on a sample of your own conversations before you decide.
Which should you choose?
- SaaS or consumer app, thousands of end users behind one backend → Supermemory
- You want facts that update and expire on their own, plus automatic user profiles → Supermemory
- You need Google Drive, Gmail, OneDrive or GitHub synced in → Supermemory
- You need SOC 2 or a HIPAA BAA now → Supermemory (Scale)
- Several agents share one memory, each with its own scoped key → Membase
- Claude Code, Cursor, Codex and ChatGPT should read the same memory as your code → Membase
- Connected apps should be read-only unless you say otherwise → Membase
- You want the full context behind a statement, not just the resolved fact → Membase
- You want to start free without modeling usage meters → Membase (beta)
Using both is reasonable too: Supermemory for per-user memory inside your product, Membase for your team’s own working memory across agents and AI tools.
Moving from Supermemory to Membase
| Supermemory | Membase |
|---|---|
| Namespace per user (user_alex) | One Membase account per user, connected by MCP consent or their own key |
| Namespace per project or space | A container (a Memory), such as Acme pilot |
| add(namespace, { content }) | add(text, container=…, custom_id=…) or memories.add(…) |
| search(namespace, { query }) | search(q, container=…, limit=…) |
| User profile | Profile (get_profile) |
| MCP spaces | Memories you tick per app on the consent screen |
- List and export your documents from Supermemory (for example with its document list and get endpoints).
- Write each one into the matching container, using the Supermemory document ID as custom_id, so re-running the import never creates duplicates.
- Keep dates: put the original date in the text when it matters, and never merge different users into one container.
- Point your agents’ SDK calls and your MCP clients at Membase.
- Keep Supermemory read access until you’ve compared answers on your own test questions.
Full walkthrough with code: How to Add Long-Term Memory to an AI Agent.
Start building with Membase
- Get an API key: Membase web app → Connect › Developer keys
- Python SDK: pip install unibaseio-membase · PyPI
- TypeScript SDK: npm install @unibaseio/membase · npm
- MCP server: setup guide · https://api.app.membase.com/mcp-http
- Videos: Add memory with the Membase SDK · Give Claude Code permanent memory (MCP)
- Docs: docs.membase.com · Help: Discord