Skip to main content
You’re using Mem0 and want to evaluate or move to Synap. This page covers how Mem0 stores memory, how its concepts map onto Synap, and how to backfill your existing data.
This page is the Mem0-specific mapping. For the method every migration shares — scope mapping, configuring your instance, pilot, verify, cut over — see How migration works.

How Mem0 stores memory

Mem0 has a single user-scoped memory bag accessed via m.add(), m.search(), m.get_all(). Memories are untyped strings. Multi-user is user_id; multi-tenant is not first-class.

The mapping

Backfill from Mem0

Mem0 stores only pre-extracted memory strings, not the original conversations, so this backfill ingests those strings directly. Where you still have the source conversations, ingest those instead — Synap re-extracts natively and produces richer, typed memories than re-processing a summary can. See why re-extraction matters.

What you gain immediately

  • Typed extractions (facts vs preferences vs episodes vs emotions vs temporal events).
  • Customer / client / user scopes, not just user.
  • Entity resolution across conversations.
  • Context compaction.

What you’ll need to adapt

Mem0’s “search returns a flat list of strings” pattern becomes “fetch returns a ContextResponse with typed lists.” Your prompt-construction code needs to iterate over ctx.facts, ctx.preferences, ctx.episodes etc. instead of one flat list — usually a few-line change. See Response shapes.

Next

Follow the shared migration method to pilot one user, verify scope isolation, swap your retrieval call sites, and cut over.