Engraphy › Compare
Engraphy, compared
Checked 24 August 2026 · Engraphy v0.1.0
The short answer
Engraphy is the pick when the properties of the memory store matter more than the speed of adopting one. It is self-hosted only, on Postgres and pgvector, with de-duplication that happens before the row exists, a schema Postgres enforces, tenants separated by row-level security, superseded facts retired rather than deleted, and an embedding model that runs in-process so a write never becomes an outbound call.
It is not the pick when you want the shortest path to a working prototype. Mem0, Zep, Letta and Cognee all have larger ecosystems, permissive licences and managed offerings; Engraphy is v0.1.0, source-available under BSL 1.1, and has no hosted option at all. Every page below says where the other system wins.
The whole field, in one table
| Capability | Engraphy | Mem0 | Zep / Graphiti | Letta | Cognee | MCP memory server | ChatGPT / Claude memory |
|---|---|---|---|---|---|---|---|
| Self-hosted with no vendor in the write path | Yes, always | Yes, on the OSS server | Graphiti only | Yes | Yes | No | No |
| Runs on Postgres alone | Yes | Configurable | No, a graph database | Postgres or SQLite | Configurable | No, a JSON file | n/a |
| De-duplicates before the row exists | Yes | LLM decides on write | Entity resolution at ingest | No | At pipeline time | No | Vendor-internal |
| Superseded facts kept and linked | Yes | May be updated or deleted | Yes, with validity windows | No | Re-ingested | No | No |
| Isolation enforced by the database | Yes, row-level security | No | No | No | No | No | n/a |
| Schema enforced on write | Yes, in Postgres | No | Typed entities, app-side | No | Inferred | No | No |
| No LLM call on the write path | Yes | No | No | No | No | Yes | No |
| Bi-temporal querying | No | No | Yes | No | No | No | No |
| Managed option available | No | Yes | Yes | Yes | Yes | No | It is the product |
Competitor rows reflect the default or most common configuration, checked 24 August 2026 against the sources linked on each comparison page. Several of these systems are configurable enough to change a cell, so treat the table as a map of the design choices, and each page for the detail.
The comparisons
Engraphy vs Mem0
The biggest name in agent memory, and the easiest to adopt. Where Engraphy differs: no model inside the engine, no delete path, and isolation the database enforces.
Read the comparison →Engraphy vs Zep
Bi-temporal validity windows on a graph database, against supersession on plain Postgres. Zep wins on time travel; Engraphy wins on what you have to operate.
Read the comparison →Engraphy vs Letta
An agent runtime where the model edits its own memory, against a memory server any MCP client can point at. Different categories, and they compose.
Read the comparison →Engraphy vs Cognee
A pipeline that turns documents into a knowledge graph, against a store for what an agent learns as it runs. These compete less than they look like they do.
Read the comparison →Engraphy vs the MCP memory server
The reference server keeps a knowledge graph in a flat JSON file for one user. What breaks first is paraphrase, and then volume, concurrency and a second person.
Read the comparison →Engraphy vs built-in assistant memory
Vendor memory needs no setup and belongs to the vendor. A memory server is work, and gives you one store every tool can read, on hardware you control.
Read the comparison →How to read these pages
Every comparison here carries a section headed Choose <the other system> when, and it is not a formality. If a page cannot name the cases where the other tool is the better answer, it is advertising rather than a comparison, and you should not trust the rest of it.
Engraphy figures carry their provenance: the run id, date, engine hash, arm, reader and judge. Competitor figures are never our measurements: where one appears, it is cited to the paper it came from, with the date and the judge that produced it.
Not comparing yet?
If you are still working out what agent memory even needs to do, the questions page answers the practical ones directly: how to get an AI to remember what you tell it, how to stop an agent storing the same fact twice, what happens when a remembered fact stops being true, and how to keep a memory store private and separated per user.
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.