Cognee

Last reviewed Aug 26, 2026 · 823 words

Cognee turns a folder of documents into a knowledge graph plus a vector index that an agent can query, and the price of that is every document you add passes through an LLM several times. The "cognify" step is the product and the bill. Budget for it before you point the pipeline at 10 GB of notes, because a local 8B model will take all night and a hosted one will send you an invoice.

Add, cognify, search: the whole API is three calls

Cognee (Apache-2.0, about 30,000 stars, Python, first released in 2023) is a library first and a service second. The minimum program:

import asyncio
import cognee

async def main():
    await cognee.add("/srv/notes/homelab-runbook.md")
    await cognee.cognify()
    hits = await cognee.search("how do I rotate the Immich database password?")
    for h in hits:
        print(h)

asyncio.run(main())

add chunks and stores the raw text. cognify is where the work happens: an LLM extracts entities and the relationships between them from every chunk, an embedding model vectorises chunks and nodes, and both land in a graph store and a vector store. search then answers by walking the graph, by vector similarity, or by a combination, depending on the search type you ask for. There is also a Docker Compose deployment that exposes the same operations over HTTP, and an MCP server so coding agents can use your corpus as memory.

The stack has five parts even when it feels like one

This is the "stack has many parts" con, and it is real. A running Cognee needs a relational database (SQLite by default, Postgres supported), a vector store, a graph store, an LLM provider, and an embedding provider. The defaults are embedded so the first run works with nothing installed: at last check LanceDB for vectors and Kuzu for the graph, both files on disk. For anything you intend to keep, switch the vector side to Qdrant or pgvector, and the graph side to Neo4j if you want to browse the graph visually, all via environment variables such as VECTOR_DB_PROVIDER and GRAPH_DATABASE_PROVIDER. Expect the 2 GB RAM floor to be the library plus embedded stores; add the memory of whatever databases you bring.

Fully local works, with a quality caveat

Point LLM_PROVIDER=ollama, LLM_ENDPOINT=http://ollama:11434/v1 and LLM_MODEL at an Ollama instance, set an embedding model the same way, and nothing leaves your network. The caveat is that entity extraction is a structured-output task, and small models are bad at it: they miss relations, hallucinate node types, and return malformed JSON that gets retried. In my runs a 14B-class model produced a usable graph and 7B-class models produced a noisy one. A pragmatic split is to run the one-time cognify with a stronger model (local if you have the VRAM, hosted if you do not) and use a small local model for the search and answer step, which is cheap and latency-sensitive. The self-hosted AI stack post covers the surrounding pieces.

When a graph beats plain RAG, and when it does not

Standard retrieval, which is a vector search over chunks, answers "find the paragraph about X" well. It fails on multi-hop questions: "which services depend on the Postgres container I am about to upgrade?" needs the link from services to database to version, spread across three documents. That is the query a graph answers and a chunk index does not. If your questions are single-hop lookups, Cognee is overkill and a vector store plus a good chunker will be faster and cheaper. The comparison with Mem0 is a different axis: Mem0 is per-user conversational memory ("the user prefers metric units"), Cognee is a knowledge layer over documents that can also hold memories. Plenty of agent stacks run both.

The APIs move fast; pin the version

The project ships often and renames things between minor versions: search types, configuration keys, and the shape of results have all changed in the time I have used it. Pin the package version in your requirements, read the changelog before bumping, and keep the raw source documents so you can re-cognify from scratch, because migrating a stored graph across a breaking release is not something I would rely on.

What I'd do

Start in a virtual environment with the embedded defaults and one folder of your own documents, and measure how long cognify takes and what the graph looks like before choosing infrastructure. If the multi-hop answers are visibly better than your existing RAG, move to Qdrant and Postgres in Compose, cognify with the strongest model you can afford once, and serve search with a small local model. If they are not better, you have your answer for the cost of an afternoon, which is the right amount to spend finding out.