Comparison

Supermemory brings in more context. ContextDB helps agents use customer details correctly.

Supermemory bundles memory, document RAG, user profiles, extractors, and connectors into one API. ContextDB does one narrower thing: decide what an agent may rely on when it acts, and record why. Claims about Supermemory below come from their public documentation as of August 2026.

Short answer: choose Supermemory when you want the widest context surface with the least assembly: hybrid search over memories and documents, auto-synced connectors, and auto-built user profiles. Choose ContextDB when your agent takes consequential actions and you need provenance, an act-ask-abstain gate, human confirmation, and a decision log. Breadth and permission are different products; some stacks want both.

Different shapes

Supermemory covers more data sources. ContextDB focuses on fewer mistakes when agents act.

Where Supermemory is genuinely strong

One API spanning memory, document RAG, profiles, extractors, and connectors (Notion, Drive, Gmail, GitHub)
Hybrid search across extracted memories and document chunks in a single query, with reranking and query rewriting
Auto-maintained user profiles built from interaction history
Multimodal ingestion: PDFs, images, video, code, processed into memories automatically

Where ContextDB is built to win

Mandatory provenance on every write; a fact without a source does not exist here
recall_for_action separates conversational relevance from permission to act
Confirmation as a workflow: pending facts, human approvals, attestation recorded with identity
A decision log and signed webhooks carrying outcomes and evidence IDs, never memory content

The load-bearing difference

Better retrieval can still surface the wrong customer detail.

Supermemory's pitch is a stronger context pipeline: more sources, better search, richer profiles. That genuinely helps conversations. But when an agent is about to move money or change an account, the binding question is not "what is the most relevant context?" It is "which of these statements is the account allowed to act on?"

A retrieval stack answers with relevance scores. A decision gate answers with provenance, confirmation status, and an explicit outcome that lands in an audit trail. If the recalled sentence is an unconfirmed wish, better ranking just delivers the wrong authorization faster.

# context stack: rank everything relevant
search("customer plan change", rerank=true)
→ 1. "asked about annual discount"   0.91
  2. "confirmed upgrade to Pro"      0.88
# ranking cannot say which one authorizes billing

# contextdb: permission, not just relevance
recall_for_action("change billing plan")
→ "confirmed upgrade to Pro"
  (user_stated · confirmed · decision recorded)
the discount question stays a question

Side by side

Compare the products by the job.

Supermemory column from their public docs and repository as of August 2026; verify against their documentation. ContextDB column reflects the shipped alpha, statuses on the changelog.

Dimension	Supermemory	ContextDB
Core job	Full context stack: memory, RAG, profiles, connectors	Decision-safe memory for agents that take action
Ingestion	Automatic: conversations, documents, connectors, multimodal	Explicit writes with mandatory source and confidence
Retrieval	Hybrid memory + document search, reranking, rewriting	Scoped recall for grounding; gated recall for action
Trust semantics	Relevance and recency signals	Source, confidence, confirmation status, policy outcome
Pre-action gate	Not a product concept	`recall_for_action`: act, ask, or abstain
Human-in-the-loop	Not built in	Pending confirmations, console approvals, MCP confirm
Audit	Not a core surface	Decision records with evidence IDs on every gated call
Scoping	Container tags per user or project	Org, project, and user partitions enforced at the store, with isolation tests
Knowledge-base RAG	First-class, including document chunks in results	Out of scope; keep your RAG, add the gate
License and hosting	Hosted platform; self-host option per their docs	Apache-2.0 SDK plus hosted platform (alpha)

When to choose which

Pick by the riskiest thing your agent does.

Choose Supermemory when

The job is knowing the user and the documents deeply, across many sources, with minimal assembly
Your agent's output is words a human reviews, not mutations it executes
Connector coverage and multimodal ingestion are the binding constraint

Choose ContextDB when

The agent executes bookings, refunds, credits, or account changes without a human in the loop
You must answer "why did the agent do that?" with evidence, after the fact
Unconfirmed statements must be structurally unable to authorize actions

Questions

Fair questions, straight answers.

Can ContextDB sit behind a Supermemory-powered agent?

Yes. Keep Supermemory for grounding and document context, and put recall_for_action in front of the tools that mutate state. The gate is a narrow API and does not care what produced the conversation.

Isn't ContextDB just doing less?

Deliberately, yes. The hosted surface is intentionally narrow, and capabilities ship only after their isolation proofs land. If you need connectors and document pipelines, use a product built for them. The thing we ship that broad stacks do not is the permission layer, and for action-taking agents that is the layer that fails loudest.

Do both handle forgetting and updates?

Supermemory documents update and forgetting flows for memories. In ContextDB's hosted alpha, deletion remains an operator action rather than an API route by design; see the trust model for what is and is not claimed.

Use Supermemory to find context. Use ContextDB before booking or refunding.

Put the gate in front of one consequential tool call and read the decision.

Run the quickstart Memory vs RAG