Engraphy vs Cognee
Checked 24 August 2026 · Engraphy v0.1.0
The short answer
Cognee is a pipeline for turning a corpus into a graph. Engraphy is a store for what an agent learns while it works. If you have a pile of PDFs, tickets, wiki pages or transcripts and you want them ingested into a queryable knowledge graph, that is exactly what Cognee's extract-cognify-load pipeline is built for, and Engraphy has no equivalent to it.
If the memory arrives one fact at a time from a running agent, and the problems are that the agent writes the same thing twice, that a fact changes next month, and that two customers must never see each other's rows, that is Engraphy's job. The write path checks each memory against what is already there before the row exists, and Postgres row-level security keeps the spaces apart.
At a glance
| Capability | Engraphy | Cognee |
|---|---|---|
| Primary input | Individual writes from a running agent, one fact at a time. | Documents and data sources, ingested in bulk through a pipeline. |
| Deployment | Self-hosted only. Postgres + pgvector, one Compose file. | Self-hosted, plus a hosted offering. |
| Licence | Business Source License 1.1, converting to Apache-2.0 at the Change Date. | Apache-2.0. |
| Storage | Postgres 16 + pgvector. One database. | Hybrid graph, vector and relational stores, with several backends supported. |
| Graph construction | Typed nodes and edges declared in a pack and enforced in Postgres. | Inferred by the cognify stage, optionally guided by an ontology. |
| Duplicate handling | Banded on write before the row exists: merge / merge-link / pending / new. | Entity resolution during the pipeline. |
| When a fact changes | Retired and linked by a supersedes edge; history stays walkable. | Typically handled by re-running the pipeline over updated sources. |
| Isolation | Postgres row-level security, per space, under a NOBYPASSRLS role. | Dataset and user scoping at the application layer. |
| How agents connect | MCP over HTTP with a bearer token. Any MCP client. | REST API, Python and TypeScript SDKs, and an MCP server. |
| Model required | None. Embeddings run in-process; no LLM inside the engine. | Yes. The cognify stage uses an LLM to extract entities and relationships. |
Which one to choose
Choose Cognee when
- Your memory starts as documents. Cognee ingests from a long list of sources and turns them into a graph; Engraphy has no document pipeline at all.
- You want the graph structure inferred for you, or guided by an ontology, rather than declared up front in a pack.
- You want Apache-2.0 with no field-of-use restriction.
- You want a bigger community, more integrations and a longer track record than a v0.1.0 engine.
- You need GraphRAG over a corpus more than you need write-time de-duplication.
Choose Engraphy when
- The memory arrives incrementally from an agent, and the same fact keeps arriving twice.
- You need isolation the database enforces, because more than one customer's memory lives in the same store.
- You need to answer what was true and when. Superseded facts are retired and linked, not replaced.
- You want no LLM in the write path: no extraction call, no API key, no egress.
- You want the memory shape declared and enforced rather than inferred, so a bad ingest cannot quietly change your schema.
These two compose better than they compete
A realistic architecture uses both. Cognee ingests the corpus that existed before the agent did (the handbook, the ticket history, the design docs) into a graph the agent can query. Engraphy holds what the agent learns after that, one write at a time, with the de-duplication and supersession that a live stream of facts needs and a batch pipeline does not.
The failure mode of using only a document pipeline for live agent memory is that every re-ingest is a full rebuild, and nothing tells you that the fact you just learned contradicts one you learned in March. The failure mode of using only Engraphy is that you have no way to get the back catalogue in.
Inferred structure versus declared structure
Cognee's cognify stage asks a model to find the entities and relationships in your documents. That is the only sane approach when the input is unstructured prose, and it is why Cognee can take a folder of PDFs and give you something queryable.
Engraphy will not infer. A pack declares the node types, the edge types, the attribute schemas and which edges may connect which types, and Postgres enforces all of it. A write that does not fit is rejected rather than accommodated. That is worse for exploratory ingest and better for a store whose shape has to stay stable while many agents write to it.
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
Is Cognee a replacement for Engraphy?
Not really. They solve different halves of the problem. Cognee turns existing documents into a knowledge graph through an extract-cognify-load pipeline. Engraphy stores what an agent learns as it runs, de-duplicating each write before it lands. Many setups want both.
Can Engraphy ingest my PDFs and documents?
No. Engraphy has no document pipeline. It is written to one fact at a time by an agent over MCP. If you need a corpus ingested into a graph, Cognee or a similar pipeline is the right tool for that half.
Which one enforces a schema?
Engraphy. Node types, edge types and attribute schemas are declared per space in a pack and enforced by Postgres, so a write that does not fit is rejected. Cognee infers structure during the cognify stage, optionally guided by an ontology.
Do I need an LLM API key for either?
For Cognee, yes: the cognify stage uses a language model to extract entities and relationships. For Engraphy, no: the embedding model runs in-process and no language model runs inside the engine, so a write never becomes an outbound call.
Sources
- Cognee on GitHub: Apache-2.0, ECL pipeline, supported stores.
- Cognee documentation: Pipeline stages, ontologies, deployment.
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.