Zep vs GraphitiManaged Memory or Self-Hosted Graph (2026)

Last tested: October 2026, Zep Cloud pricing and the zep-cloud Python SDK v3, graphiti-core 0.30.

Zep and Graphiti are not rivals. Graphiti is the open-source engine, and Zep Cloud is the managed service its authors run on top of it. So the choice is not which graph is better. It is who operates the graph, and where your users’ facts are stored.

TL;DR: Zep vs Graphiti, which one?

Pick Zep Cloud when you want user and thread memory as an API, an SLA and no graph database to run; self-serve starts at $125 a month. Pick Graphiti, under Apache-2.0, when facts must stay in your infrastructure, you need an EU data processing agreement without enterprise pricing, or you want control over extraction and storage.

Recommended path: decide by where the data must live

Start with the data, not the features. If the memory will hold personal data of EU customers and you are not buying Enterprise, self-host Graphiti in your own EU environment, because Zep lists its DPA for EU customers only in the Enterprise column. If the memory holds no personal data, or you are prototyping, start on Zep’s free tier and measure your real episode volume before you commit to either side.

For most DACH B2B teams I work with, that means Graphiti on FalkorDB or Neo4j inside their own cloud account, with Zep as the benchmark for what the memory layer should feel like.

The same memory in each

Zep gives you users, threads and an assembled context string:

import os
from zep_cloud.client import Zep
from zep_cloud.types import Message

client = Zep(api_key=os.environ["ZEP_API_KEY"])
client.user.add(user_id="u-4711", first_name="Jana")
client.thread.create(thread_id="t-001", user_id="u-4711")
client.thread.add_messages(thread_id="t-001", messages=[
    Message(name="Jana", role="user", content="We moved the rollout from Q3 to Q4."),
])

context = client.thread.get_user_context(thread_id="t-001")
print(context.context)  # ready for the system prompt

Graphiti gives you episodes and search. The user, the thread and the context string are yours to build:

from datetime import datetime, timezone
from graphiti_core import Graphiti
from graphiti_core.nodes import EpisodeType

graphiti = Graphiti("bolt://localhost:7687", "neo4j", "change-me")
await graphiti.build_indices_and_constraints()

await graphiti.add_episode(
    name="t-001-msg-1",
    episode_body="Jana: We moved the rollout from Q3 to Q4.",
    source=EpisodeType.message,
    source_description="support chat",
    reference_time=datetime.now(timezone.utc),
    group_id="u-4711",
)

edges = await graphiti.search("When is the rollout?", group_ids=["u-4711"])
context = "\n".join(edge.fact for edge in edges)

The gap between those two snippets is the product Zep sells: user management, thread handling, context assembly, retries and rate limits, all behind one API key.

What Zep Cloud costs, worked out

Zep meters ingestion only. An episode costs one credit up to 350 bytes, plus one credit per additional 350 bytes. Retrieval, storage, threads and users cost nothing.

Measure your average episode size before you pick. A chat turn and a pasted email differ by an order of magnitude.

What Graphiti costs instead

There is no license fee, and that is the only line that is zero. Each episode triggers several LLM calls for entity extraction, deduplication and summaries, plus embedding calls. On top come the database host, backups, upgrades and the engineer who watches the rate limits.

Measure it instead of estimating it. Ingest 100 real episodes and read the token usage from your provider dashboard:

monthly cost = episodes × (LLM tokens per episode × price per token)
             + embedding cost + database host + engineering hours

Graphiti also runs with a local model through Ollama, which moves the token cost to your own hardware. Check extraction quality on your own text first; small models produce more failed episodes.

Where the two drift apart

• Open source. Zep Community Edition is deprecated and unsupported. If you still run it, the migration targets are Graphiti or Zep Cloud.
• Schema. Zep caps custom entity and edge types at 10 or 20. Graphiti takes whatever Pydantic models you define.
• Only in Zep. Observations, webhooks and analytics on Flex Plus, user context assembly, an SLA on Enterprise.
• Only in Graphiti. Your choice of database, offline operation, and an approval step before any fact is written.

Keep the exit door open

Both sides ingest episodes. Whichever you choose, store every raw episode in your own system before it goes into the graph. With the raw episodes, switching from Zep to Graphiti or back is a replay job. Without them, it is a graph export project. I wire this in on every knowledge graph engagement, because the graph is rebuildable and the source material is not.

Changelog

• 2026-10-12: First version, with Zep Cloud’s self-serve pricing and credit rules as published in October 2026 and the zep-cloud v3 SDK calls.