Ideas

TinyContext vs. Mem0 and Zep: Memory for AI Agents Without a Second Database

August 15, 2026

Give an agent memory and you’ve usually also signed up to run a second piece of infrastructure. Mem0 and Zep, the two names that come up most in “AI agent memory” searches, both work well, and both assume a vector store or a graph database sitting next to them. TinyContext exists for the case where that assumption doesn’t hold: a local agent that needs durable memory and nothing else to operate.

Mem0: an extraction pipeline in front of a vector store

Mem0 positions itself as the memory layer for AI agents. Mechanically, it’s an LLM extraction step in front of a vector database: an LLM call reads each conversation turn, decides what’s worth remembering, and reconciles it against existing memories with an add, update, or delete operation before writing it to a vector store. An optional graph memory mode adds entity linking on top.

That’s a capable design, and it’s open source under Apache 2.0 if you want to self-host it. Self-hosting, though, means running the reference stack: FastAPI plus Postgres with the pgvector extension, and Neo4j if you want graph memory, alongside the LLM and embedding API calls that extraction itself requires. Mem0 also offers a hosted platform with a metered free tier and paid plans that gate graph memory and analytics behind higher tiers.

The core tradeoff is that every write costs an LLM call before it costs a database write. For an agent that’s already saving structured facts it knows are worth keeping, that extraction step is overhead it doesn’t need.

Zep: a temporal knowledge graph, now cloud-first

Zep has moved further from “memory API” toward “context engineering platform” built on a bi-temporal knowledge graph. Its open-source core, Graphiti, tracks facts as graph edges with valid-from and valid-to timestamps, so a fact that gets contradicted later is marked invalid rather than silently overwritten, and each fact keeps a record of where it came from.

The detail that matters most if you’re evaluating Zep in 2026: Zep Community Edition, the self-hostable version, has been deprecated. Self-hosting Zep’s approach now means running Graphiti yourself against your own graph database, such as Neo4j, FalkorDB, or Kuzu, rather than deploying a packaged Zep server. Zep’s own hosted product remains, priced on a credit basis with enterprise tiers for SOC 2 and HIPAA needs.

Graphiti’s temporal graph model is genuinely well suited to memory that changes over time and needs to reconcile contradictions. It’s also a heavier piece of infrastructure than a lot of agents need, and running it yourself is now a build-your-own-server exercise rather than a supported deployment path.

What TinyContext does instead

TinyContext stores memory in a single SQLite database. No Postgres, no pgvector, no Neo4j, no separate vector service. Text and float32 embeddings live in the same file, using sqlite-vec for the similarity search, which is also what makes save_memories, recall_memories, update_memory, and delete_memory work as plain MCP tool calls, a Python library, or an optional self-hosted Docker and FastAPI stack, without provisioning anything first.

Retrieval combines BM25 lexical search with local ONNX-embedding dense search, fused with weighted reciprocal rank fusion, so a recall call gets both keyword matches and semantic matches ranked together rather than relying on embeddings alone. Results come back labeled by relevance (high at a fused score of 0.90 or above, medium at 0.75, everything else admitted as low) and trimmed to a token budget, so recall returns only what the model can use instead of resending the full memory store. Calling recall_memories without a query switches to a bounded, newest-first recent view instead of semantic ranking, which matters for the ordinary case of just wanting the last few things that happened rather than a topical match.

There’s no LLM extraction step on write. save_memories persists the facts the agent already decided are worth keeping, without a separate model call deciding what mattered, and writes are deduplicated against near-identical existing memories automatically. That’s a narrower job than Mem0’s automatic extraction or Zep’s temporal reconciliation, and it’s the tradeoff that lets TinyContext skip the second database entirely. TinyContext does keep one piece of Mem0 and Zep’s write-time thinking, in a lighter form: update_memory supersedes a stale fact with a corrected one rather than deleting and re-adding it, preserving the relationship between old and new versions and returning a stable short ref you can pass back in future calls.

TinyContext also separates two kinds of memory that Mem0 and Zep generally treat as one pool. Durable identity and preference facts, like what to call a user or how they prefer to work, can be saved as profile memories instead of the default episodic kind. Profile memories are global to the store, aren’t semantically ranked against a query, and are automatically attached to every recall inside their own budgeted block, so an agent doesn’t have to re-retrieve “the user prefers concise answers” every time it happens to rank well against the current question.

Running it for more than one person

TinyContext’s default stdio and single-container Docker setups are single-user by design: one SQLite file, one owner. For teams that need a shared, hosted deployment, TinyContext has a separate hosted-tenancy mode rather than pretending the single-user setup scales to it. An authenticated reverse proxy strips any client-supplied identity header and injects a verified one; TinyContext only accepts requests from configured trusted proxy CIDRs and returns 401 on a missing or ambiguous identity. Each tenant gets an isolated SQLite database with an HMAC-derived filename, so raw user IDs never appear in the filesystem, and one session_id never crosses between tenants. All tenants in a container share one loaded embedding model and its cache; only the stored memories and vectors are separated.

The measured tradeoff

TinySuite doesn’t claim TinyContext’s retrieval quality matches a full extraction pipeline or a temporal graph on hard, contradiction-heavy memory tasks; that’s an open, harder evaluation the project hasn’t run yet. What’s measured is the token cost of recall itself and how it holds up as a memory store grows. Across corpus sizes in TinyContext’s published benchmark, recall latency stayed in the tens to low hundreds of milliseconds even as the store grew from 100 to 5,000 memories:

Against resending 300 stored memories raw, TinyContext used 96.7% fewer input tokens across a synthetic eight-query benchmark. A separate synthetic accuracy test reached 100% recall@k and a perfect MRR of 1.00, but only on semantically distinct planted facts; that confirms the retrieval mechanism works, not that it holds up against confusable memories or real, messy conversational history. The benchmark scripts are public and reproducible against your own hardware.

If your agent needs automatic fact extraction from open-ended conversation or a temporal graph that reconciles contradictions over time, Mem0 or Graphiti-based Zep are doing a real job TinyContext doesn’t attempt. If your agent already knows what’s worth remembering and you want that memory to live in one file with no extra services to run, that’s the gap TinyContext fills. Install TinyContext or read more about how TinySuite treats context as a budget.

Back to all posts