Skip to main content
All comparisons
Head-to-head

Ricord vs MemoBase: AI Memory Comparison (2026)

MemoBase ships a user-profile memory layer purpose-built for B2C companion apps and chatbots — Profile + Event model, Apache-licensed OSS, hosted option. Ricord ships a general-purpose knowledge layer for agents that need to remember any topic, not just the user. Honest side-by-side.

Quick compare

FeatureRicordMemoBase
Memory scopeAny topic, any entityUser profile + events
Primary use caseAI agents (dev tools, ops, knowledge work)Companion apps, chatbots
Product shapeHosted SaaS (API + MCP)OSS library + Memobase Cloud
LicenseProprietary SaaSApache 2.0
Starts at$15/mo annual$0 OSS / self-host + LLM costs
MCP server (Claude Desktop / Code / Cursor / Codex / Zed / Gemini CLI)13 tools
Conflict resolution at ingestProfile update merge only
Knowledge graphIncluded every paid tier
Auto-generated wiki pages
Browsable dashboard UIProfile viewer only
Primary SDKTypeScriptPython
Hard delete (GDPR)You wire it
Cross-client memory (same memory from Claude Desktop + Cursor)

The honest positioning difference

MemoBase and Ricord are not really substitutes — they target adjacent problems with different shapes.

MemoBase is purpose-built for one shape: building a structured user-profile for a long-running B2C chatbot or AI companion. Their data model is Profile + Event. The profile is the evolving structured picture of who the user is — name, preferences, relationships, history. Events are timestamped behavior. The product is opinionated about this shape and ships a clean SDK and a profile-viewer dashboard that suit it.

Ricord is built for general knowledge memory across anyentity, not just the user. What does the codebase do? What did we decide last sprint? What does the customer want? Who is this person we're onboarding? Each of those questions lives in the same graph, with auto-generated wiki pages for every topic and conflict resolution at ingest.

If your product is a companion app and the memory IS the user profile, MemoBase's shape is closer to the problem. If your product is an AI agent that needs to remember code, decisions, projects, and many entities (the user being one of them), Ricord's shape fits better.

Data-model deep dive

MemoBase: Profile + Event

MemoBase stores one Profile per user (a structured JSON blob with typed slots — personality, location, preferences, relationships, etc.) plus an append-only stream of Events. The profile updates as events accumulate. The retrieval API returns the current profile as a context block your agent can include in its prompt.

Strengths of this shape: extremely tight context block, easy to inject into a system prompt, hard to overflow your context window. Weaknesses: anything that doesn't fit into "who is the user" needs to be modeled differently or pushed somewhere else.

Ricord: Entities + Edges + Wiki Pages

Ricord stores memories as facts attributed to entities, with edges between entities, forming a graph. Wiki pages are auto-generated per entity — the user, a project, a file, a decision, a customer, a meeting. Recall is semantic + graph-walked, returning the relevant subset for the current question.

Strengths of this shape: scales to any topic the agent encounters without schema work. Weaknesses: context blocks are computed at recall time rather than always-on, which is fine for tool-using agents and worse for tight-loop chat where you want a single profile injected on every turn.

Where Ricord wins

  1. Memory beyond the user.Code, decisions, projects, tickets, customers — each gets a wiki page in Ricord. MemoBase's profile model is the user; other entities need to be modeled outside MemoBase or shoved into the profile blob.
  2. MCP-native install. MemoBase has no MCP server; you call it from your agent code over HTTP. Ricord drops into Claude Desktop, Claude Code, Cursor, Codex, Zed, and Gemini CLI with three commands and a restart. No agent-code changes.
  3. Conflict resolution at ingest. MemoBase updates the profile when events come in but doesn't reason about contradictions across the broader knowledge surface. Ricord does this at write time — when a new fact contradicts an existing one, the old one is marked superseded, and recalls return the current truth.
  4. Browsable wiki UI.MemoBase ships a profile viewer — useful for a single user's picture. Ricord ships a dashboard with auto-generated wiki pages per entity, backlinks, and a 3D graph view of how everything connects.
  5. TypeScript-first SDK. MemoBase is Python-first with a TypeScript port. Ricord ships a first-class TypeScript SDK alongside REST + MCP, which matters for Node / Next / Cloudflare Workers / Deno agents.

Where MemoBase wins (honestly)

  • Companion / chatbot fit.If your product is a long-running AI companion, customer-support chatbot, or personalized assistant, MemoBase's data model is the closest mainstream OSS option to the problem. Profile-as-context is the right primitive for that pattern.
  • Apache 2.0 license.Permissive license, no flowthrough constraints. Modify and ship without license review. (Same family as Mem0's license, looser than Cognee's AGPL.)
  • Self-host is straightforward. Postgres + an LLM API key. The infra footprint is smaller than graph-based alternatives — no separate graph database, no embedding service to operate (LLM provider handles it).
  • Tight context blocks.The profile-as- JSON output is small and stable, which makes prompt budgeting predictable in a way that semantic recall isn't.

Known MemoBase gotchas

  • Profile schema design lives with you. You define the slots in the profile up-front. Adding a new slot for a behavior you didn't anticipate is a schema change with backfill cost. Ricord's entity-extraction picks up new fact shapes without schema work.
  • Profile size grows. As you add slots to capture more about the user, the profile context block grows. Long-running users with rich histories can produce profile blobs that cost real token budget every turn.
  • Events ≠ knowledge graph.The event stream is append-only and not entity-extracted across entities other than the user. If you need "tell me about Project X" or "what did we decide about deploys," you'll be building that elsewhere.
  • Hosted is newer. Memobase Cloud is available but enterprise features (multi-region, audit trails, custom SLAs) lag the self-host story. Evaluate carefully for production workloads.

Migrating from MemoBase to Ricord

The two products store different things, so migration is an additive step rather than a swap. Most teams running both keep the profile-as-context pattern from MemoBase for the user-facing chatbot and add Ricord for the agent's broader memory (code, decisions, customers, projects). Where they overlap (user facts), Ricord's entity extraction picks the user up automatically.

If you do want to fully replace MemoBase with Ricord, export the profile as JSON and bulk-import each attribute as a memory tagged to the user:

# Replay MemoBase profile slots into Ricord memories
for slot, value in memobase_profile.items():
    requests.post(
        "https://api.ricord.ai/v1/memories",
        headers={"Authorization": f"Bearer {RICORD_KEY}"},
        json={"user_id": user_id, "content": f"{slot}: {value}"},
    )

Conflict resolution at ingest will deduplicate as the data lands. The wiki view populates within an hour and the user gets their own auto-generated page.

When each wins — at a glance

Pick MemoBase if:

  • Your product is a companion / chatbot / personalized B2C assistant
  • The memory you need IS the user profile
  • You want OSS with a permissive license and a small infra footprint
  • Profile-as-context block on every turn is the retrieval pattern you want

Pick Ricord if:

  • You're building AI agents (dev tools, ops, knowledge work) that need to remember any topic
  • You want MCP-native install across Claude Desktop / Cursor / Codex / Zed / Gemini CLI
  • You need a browsable wiki of what the agent learned, not just the user's profile
  • You want hosted ops + conflict resolution + GDPR delete by default

Try Ricord

bun add -g ricord
ricord login
ricord install

Three commands. Restart your MCP client. The agent starts saving and recalling immediately; the wiki populates over the next week.