memorg vs Mem0: Structured Memory vs Vector Memory for LLM Agents

The question

Should I use memorg or Mem0 for my agent’s memory?

This comes up in almost every conversation about long-running agents. Both give an LLM application information that survives across sessions, but they make different bets about what should be stored. The choice shapes your agent’s architecture, so it is worth understanding the trade-off before you commit.

The 60-second version: Mem0 uses an LLM to extract facts from conversations and stores them for similarity search; memorg stores the conversations themselves, in an organised hierarchy, and retrieves from them with hybrid vector-plus-keyword search. Mem0 gives you distilled facts; memorg gives you the record.

What Mem0 is

Mem0 describes itself as a self-improving memory layer. It uses an LLM to extract facts from conversations, embeds them, stores them in a vector store (it supports several, with Qdrant as the default), and surfaces the most relevant ones at query time:

from mem0 import Memory

m = Memory()
m.add("User prefers dark mode and concise answers.", user_id="alice")
results = m.search("What does the user prefer?", user_id="alice")

The mental model is: conversation → extracted facts → embeddings → similarity search → context. It is fast to set up, integrates with the major LLM frameworks, and works well for the “remember the user’s preferences” use case.

What memorg is

memorg is an external memory layer for LLMs, in Python. It organises conversation history as a hierarchy — session → conversation → topic → exchange — and stores other material (documents, notes, entities, or custom types) as tagged memory items with optional parent/child links. Records live in SQLite, each table mirrored into an FTS5 full-text index; embeddings come from OpenAI and are indexed with USearch in the same place.

from memorg import MemorgSystem
from memorg.storage.sqlite_storage import SQLiteStorageAdapter
from memorg.vector_store.usearch_vector_store import USearchVectorStore
from openai import AsyncOpenAI

system = MemorgSystem(
    storage=SQLiteStorageAdapter("memorg.db"),
    vector_store=USearchVectorStore("memorg.db"),
    openai_client=AsyncOpenAI(),
)

session = await system.create_session("user_1", {"max_tokens": 4096})
conversation = await system.start_conversation(session.id)
topic = await system.context_store.create_topic(conversation.id, "Project Help")

await system.add_exchange(
    topic.id,
    user_message="How do I handle authentication?",
    system_message="You can use JWT tokens or session-based auth...",
)

results = await system.search_context("authentication")

Retrieval embeds the query, takes nearest neighbours from USearch, falls back to FTS5 keyword search when the vector search comes up short, and ranks the merged candidates by a mix of semantic similarity, recency and importance. Each result records whether it matched by keyword, meaning, time or importance. memorg also manages the context budget — recency prioritisation, extractive summarisation and token-budgeted working memory — and ships a CLI and an MCP server (memorg-mcp).

The mental model is: conversation → stored exchanges → hybrid retrieval → context. Nothing is distilled away; what you get back is what was said, ranked.

The dimensions that matter

Dimension	Mem0	memorg
What gets stored	Facts extracted by an LLM	The exchanges themselves, plus memory items you add
Organisation	Scoped by user, agent or run	Session → conversation → topic → exchange; tagged items
Storage	Pluggable vector store (Qdrant default)	SQLite with FTS5, plus a USearch index alongside
Retrieval	Vector similarity over extracted facts	Vector search with keyword fallback, multi-factor ranking
LLM in the write path	Yes: extraction decides what is kept	No: records are stored as given, then embedded
Inspectability	Facts are short strings you can list	Records are rows you can query with SQL
Failure mode	Extraction misses or misstates a fact	Retrieval surfaces a verbose or stale exchange
Interfaces	Python and JS SDKs, hosted platform	Python library, CLI, MCP server
Licence	Apache-2.0	MIT

Neither project publishes a benchmark that settles which recalls better, and we do not quote one. Memory quality depends heavily on the conversations involved, so if it matters, build a small labelled set of “what should the agent remember here?” questions from your own transcripts and test both.

When to use which

Use Mem0 when:

The use case is “remember the user’s preferences” or “remember what we discussed last time”, and a compact set of distilled facts is exactly what you want in the prompt.
You want a hosted option and SDKs in more than one language.
You are happy for an LLM to decide what is worth keeping.

Use memorg when:

You want the record, not a summary of it: the exchanges themselves, organised by conversation and topic, retrievable verbatim.
You want to inspect the memory with ordinary tools — it is a SQLite file — and answer “what did the agent have available?” by query rather than by inference.
You want memory over MCP, so an MCP client can use it as an external memory without custom integration code.
You want to keep the write path free of LLM calls beyond embedding, so nothing is lost or rewritten on the way in.

Use both when you want distilled facts for the prompt and the full record behind them: extracted preferences from Mem0 for the common case, and memorg’s searchable history when the agent needs to check what was actually said. That combination is a design pattern, not a packaged integration.

The auditability question

The biggest practical difference is what you can inspect after the fact. With extracted-fact memory, the original wording has been interpreted by a model before it was stored; to answer “what did the agent know when it made decision X?”, you have the facts, and the extraction step between them and the conversation.

memorg keeps the conversation. Every exchange is a timestamped row, so you can see what was stored and when, and each search result says how it matched. That is not a compliance programme — retention, erasure and access control are still yours to design — but it is a better starting point for one. Because memorg exposes an MCP server, an MCP-layer proxy such as mpl could in principle sit between agent and memory to keep a tamper-evident record of the calls; we have not published a tested configuration for that.

For consumer products this gap may not matter. For systems where someone will later ask what the agent knew, it often does.