Engraphy vs Zep
Checked 24 August 2026 · Engraphy v0.1.0
The short answer
Zep is the better choice if you genuinely need bi-temporal querying: asking what the store believed at an arbitrary past instant, not just what it believes now. Graphiti gives every edge a validity window, and Engraphy does not have that. Engraphy is the better choice if you want the whole thing on one Postgres instance you already know how to run, with isolation enforced by the database and embeddings that never leave the box.
The operational difference is large. Zep today is either Zep Cloud (managed, credit-based) or standing up Graphiti yourself against Neo4j, FalkorDB or Kuzu. The Zep Community Edition was deprecated. Engraphy is docker compose up and a Postgres database.
At a glance
| Capability | Engraphy | Zep |
|---|---|---|
| Deployment | Self-hosted only, on Postgres + pgvector. One Compose file. | Zep Cloud (managed, credit-based), or run the Graphiti library yourself against a graph database. |
| Where your data lives | Your machine or your cloud. Embeddings in-process, no egress. | Zep's cloud, or your own graph database with Graphiti. LLM extraction calls a provider either way. |
| Licence | Business Source License 1.1, converting to Apache-2.0 at the Change Date. | Graphiti is Apache-2.0. Zep Cloud is commercial. Zep Community Edition is deprecated. |
| Storage | Postgres 16 + pgvector, one database you probably already operate. | A temporal knowledge graph on Neo4j, FalkorDB or Kuzu, plus a vector index. |
| Duplicate handling | Banded on write before the row exists: merge / merge-link / pending / new. | Entity resolution at ingest, driven by an LLM. |
| When a fact changes | Retired and linked by a supersedes edge. History is walkable. | Bi-temporal validity windows. Edges carry valid-from and valid-to, so you can query a past state directly. |
| Isolation | Postgres row-level security under a NOBYPASSRLS role. | User and session scoping in Zep Cloud; on raw Graphiti, whatever you build. |
| Schema | Typed nodes and edges with attribute schemas, enforced in Postgres. | Custom entity and edge types defined in Python. |
| Retrieval | Vector plus Postgres full-text fused with reciprocal rank fusion, plus graph traversal. | Hybrid semantic and BM25 search with graph traversal and rerankers. |
| How agents connect | MCP over HTTP with a bearer token. | SDK and REST API; a Graphiti MCP server exists. |
| Compliance | None claimed. You are the operator, so the posture is yours. | Zep Cloud carries SOC 2 Type 2 and HIPAA. |
Which one to choose
Choose Zep when
- You need real bi-temporal queries. This is Zep's sharpest advantage and Engraphy does not match it. Engraphy retires and links superseded facts, which makes history walkable, but it is not the same as querying an arbitrary past instant.
- You want a managed service with SOC 2 Type 2 and HIPAA behind it. Engraphy has no hosted offering at all.
- You are already running a Neo4j-class graph database and want to use it.
- You want Apache-2.0 with no field-of-use restriction, and Graphiti as a library rather than a server.
- You want a much larger community and a longer track record than a v0.1.0 engine has.
Choose Engraphy when
- You would rather operate one Postgres than a graph database plus a vector index. Engraphy's whole store is Postgres 16 with pgvector.
- You want no outbound calls on the write path. Engraphy's embedding model runs in-process; there is no API key.
- You need isolation the database enforces rather than the application. Row-level security under a NOBYPASSRLS role, per space.
- You want the borderline duplicate handed back to you rather than resolved by a model.
- You want a memory shape you declare and Postgres enforces, rather than one the ingest pipeline infers.
Bi-temporal versus supersession: the difference matters
Both systems refuse to overwrite history, but they do it differently, and Zep's version is more powerful.
Graphiti gives each edge a validity window. A fact is not just true or retired; it is true between these two instants, and the graph separately records when the system learned it. That lets you reconstruct the state of the world at an arbitrary past moment.
Engraphy records the new version and keeps the old one linked by a supersedes
edge. You can always ask what was true and when, by walking the chain. What you cannot do is
issue a single query for “the state of this space as of March”. Full bi-temporal
querying is not built. If your problem is auditing a changing world, such as contracts, prices
or org charts, that gap is the reason to choose Zep.
The operational bill is very different
Since the Community Edition was deprecated, self-hosting Zep means running Graphiti directly: standing up and operating Neo4j, FalkorDB or Kuzu, handling schema migrations, and keeping a graph database healthy in production. That is a real skill set and a real cost.
Engraphy is a Postgres application. docker compose up -d brings up Postgres and
pgvector, runs the migrations, provisions a non-superuser app role, and starts the MCP server.
If your team already backs up and monitors a Postgres, Engraphy adds a schema to something you
already run rather than a new class of database to learn.
What the benchmark says, and what it does not
On LoCoMo, Engraphy scores 67.1% and Zep 66.0%. That gap is well inside Engraphy's confidence interval of 62 to 72, so it is not a result. The two read as level. The figure that does separate them is temporal reasoning, where Engraphy scores 76.0% [67 to 83] against a best published figure of 58.1%, held by Mem0-graph rather than Zep.
Zep leads clearly on open-domain knowledge questions, at 76.6% against Engraphy's 57.7% [39 to 74]. Those questions lean on world knowledge rather than on what the conversation stored, and only 26 of them were in scope for our run, which is why that interval is so wide.
What the benchmark says
LoCoMo accuracy with the adversarial category excluded, the denominator every published figure here uses. Engraphy's 95% confidence interval runs 62 to 72 and covers Mem0-graph, Mem0 and Zep. Engraphy is statistically level with the leaders of the field, not ahead of them.
Engraphy: run fullrun-conv-20260809, 9 August 2026, engine 631e7be7b23e, 500 questions across 3 of the 10 LoCoMo conversations (389 of them non-adversarial), arm llm-conversational/search_only, reader claude-opus-4-8, judge claude-sonnet-5 best of three. The competitor figures are not our measurements: they are from Chhikara et al., Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory, arXiv:2504.19413v1, 28 April 2025, Table 2 for the overall column and Table 1 for the per-type figures, measured with a gpt-4o judge over all ten conversations. Different judges and a different question count, so this places Engraphy among these systems rather than ranking it against them.
What Engraphy does not do
Stated plainly, so that nothing here has to be walked back:
- A near-verbatim restatement can lose its text. If an incoming body
overlaps the stored one at a Jaccard of 0.8 or above it is not added as an addendum,
and the write returns
addendum_added: false. Nothing is deleted, and not everything written is kept as new text. - Contradictions merge. A negation sits close in meaning to the fact it
overturns, so it scores above the merge threshold and is absorbed, measured at 28
of 36 pairs in our own contradiction set. The merge result names what it merged into, so
the caller can repair it with
supersede. The engine will not guess, because agreement is a judgment call and no model runs inside the engine. - Time travel goes as far as supersession, not further. Facts are retired and linked rather than overwritten, so history is walkable. Full bi-temporal querying, asking what the store believed at an arbitrary past instant, is not built.
- Ranking is reciprocal rank fusion today. The cross-encoder slot is specified and stays disabled until there is evidence it earns its cost.
- It is v0.1.0, and it is self-hosted only. There is no managed Engraphy to sign up for. You run Postgres, or nothing runs.
Questions people ask
Does Engraphy support bi-temporal queries like Zep?
No. Engraphy retires superseded facts and links them with a supersedes edge, so history is walkable and you can ask what was true and when. Full bi-temporal querying, asking for the state of the store at an arbitrary past instant in one query, is not built. Zep's Graphiti does have validity windows on edges.
Can I still self-host Zep?
The Zep Community Edition was deprecated and its code moved to a legacy folder. Self-hosting today means running the Graphiti library yourself against Neo4j, FalkorDB or Kuzu, and operating that graph database in production. Engraphy self-hosts on Postgres with pgvector.
Which needs less infrastructure, Engraphy or Zep?
Engraphy. Its entire store is Postgres 16 with the pgvector extension, brought up by one docker compose command. Graphiti needs a graph database plus a vector index, and Zep Cloud needs no infrastructure at all but is a managed service you send data to.
Does either one keep my data on my own machine?
Engraphy always does. It is self-hosted only and its embedding model runs in-process, so there is no API key and no egress on the write path. Graphiti can run on your infrastructure but calls an LLM provider for extraction. Zep Cloud is a hosted service.
Is Zep or Engraphy better for compliance?
Zep Cloud carries SOC 2 Type 2 and HIPAA, which Engraphy has no equivalent of because there is no hosted Engraphy. What Engraphy gives you instead is that the data never leaves your infrastructure and tenant isolation is enforced by Postgres row-level security.
Sources
- Graphiti on GitHub: Apache-2.0, bi-temporal knowledge graph, supported graph backends.
- Announcing a New Direction for Zep's Open Source Strategy: The deprecation of Zep Community Edition.
- Chhikara et al., arXiv:2504.19413v1: Source of the Zep LoCoMo figure quoted here, 28 April 2025.
Try it against your own memory
Engraphy is a server you host. Point any MCP client at it. Embeddings run in-process, so there is no API key and no data leaves the box.