What is GraphRAG?
GraphRAG replaces similarity search over embedded chunks with a graph: a model extracts the entities in your documents and the relations between them, and a question is answered by walking those relations instead of by finding text that looks similar. Building it costs a full extraction pass over the corpus, and what it buys is the ability to answer questions whose answer is a path or a pattern rather than a passage.
What changes when you build a graph instead of an index
A vector index answers a question by finding text that looks like the question. That works when the answer is a passage, and it has no way to express the two things it is built without: a relation between two things, and a property of the whole collection.
A graph-based system inserts a step between the documents and the answer. A model reads the text and emits entities and the relations among them, as triples or as typed edges, and those are stored in a graph. A query then becomes either a lookup of specific nodes and their neighbourhood, or a traversal, and the retrieved material is a set of relationships rather than a set of chunks.
That buys two things vector search cannot do. Multi-hop questions, where the answer is a path: which service calls this one, who approved what after whom, what breaks if this table goes away. And aggregate questions, where the answer is a property of the corpus: what are the recurring themes, how did this topic's treatment change over the years, which of these fifty incidents share a cause. There is no passage that answers those, because the answer is the shape of the collection.
It also introduces a step that cannot fail loudly. Extraction is a model call, so a mis-extracted relation becomes an edge, and a wrong edge produces a confidently wrong multi-hop answer. Everything downstream treats the graph as fact, because by then it is indistinguishable from fact.
Three shapes, three purposes
The projects in this area look similar from the outside and answer different questions, and the difference matters more than the shared vocabulary.
The community-summarisation index. This is the pipeline microsoft/graphrag popularised: extract entities and relations, run community detection over the graph so that groups of related entities form communities, and then have a model write a summary of each community. Those summaries become an index of their own. A question about a specific entity is answered from its neighbourhood, and a question about the whole collection is answered by working across the community summaries. Our analysis of microsoft/graphrag describes exactly that shape, and it also notes the README now says the project is largely in maintenance mode, which changes who should adopt it and why.
The accumulating memory graph. getzep/graphiti builds graphs where facts carry validity windows and every derived claim traces back to an episode that produced it. That is a different goal: not answering a question about a static corpus, but letting an agent remember what it learned and know when that knowledge stopped being true. Its cost is a graph database you run yourself, which our analysis names as the expectation.
The deterministic code graph. For source code, the entities and relations are already written down, and a parser can read them exactly. Graphify-Labs/graphify is the clearest example: its description is turning a codebase with its docs, SQL schemas, configs and PDFs into a queryable knowledge graph, with local deterministic AST parsing, every edge explained and no vector store, and our analysis says code is parsed deterministically without sending anything to a remote server while docs and PDFs go through a semantic pass with a configured API key. Here the graph is a compiler artifact rather than a guess, and the only model call is for prose.
When the graph is worth building
The case is specific, and it is about the shape of the question rather than the size of the corpus.
It fits aggregate questions. Summarise the themes across a support archive, track how a policy changed over a decade, find the topics that recur in a year of incident reports. Vector retrieval structurally cannot serve these, and a model reading everything at once can only serve them for a corpus small enough to fit.
It fits relational questions. Dependencies between services, the chain of approvals behind a decision, the people involved in a project over time. If your answer is a path, a graph is the right structure.
It fits memory that changes. An agent that learns a fact this week and must stop relying on it next month needs somewhere to put validity and provenance, and that is what a temporal graph is.
It fits code. The relations are exact, the update is incremental because a commit changes specific symbols, and the question set is genuinely relational.
It does not fit the ordinary case. Single-document lookup, a user asking for the page that contains a specific sentence, is better served by search, and a graph adds a build step to answer it. It does not fit a corpus that changes faster than you can re-extract: the graph is a snapshot, and a snapshot that is a day behind is worse than an index that is always slightly behind. It does not fit when the extraction problem is hopeless, because entities that cannot be resolved produce a graph with three nodes for one person and no query will help.
Where it breaks
Five failure modes, and the first two account for most of them.
Entity resolution. The same organisation written three ways, a person's name colliding with another person's, an abbreviation that expands differently per document. Each variant becomes a separate node, the graph fragments, and multi-hop paths break at the join. This is the problem that decides whether a graph is useful, and it is the hardest part to fix after the fact.
Cost proportional to the corpus. Extraction is a model pass over everything, and the community-summarisation variant adds a second pass with a large context per community. On a large corpus this is the dominant cost, paid before any query is answered, and unlike an index it does not amortise across cheap queries: it is the price of admission.
Staleness. A graph is a snapshot at index time. Incremental update solves it for code, where a commit tells you what changed, and much less well for prose, where a new document can contradict an existing entity without touching it.
Determinism. Extraction is a model call, so the same corpus indexed twice can produce different graphs, and the same question answered twice can traverse different paths. A vector index has the same property in its scores and much less in its structure.
Schema rigidity. Fix the entity and relation types and extraction gets cleaner but the graph stops representing what you did not think of. Leave them open and the graph fills with nodes that mean nothing. Most systems pick one and the choice shows up in the quality of the answers.
How the projects divide
Four groups, and the group tells you whether your graph is a summary, a memory, or a map.
The reference pipeline. microsoft/graphrag is the implementation of the community-summarisation approach, and the maintenance note in its README is the practical thing to check before you start a new deployment on it.
Memory engines for agents. topoteretes/cognee turns ingested documents into a knowledge graph plus a vector index so agents can recall context across sessions; our analysis describes it as an Apache-2.0 Python library that installs with pip, needs an LLM key, and whose own README warns that its defaults trade latency for memory quality. getzep/graphiti is the temporal version, with validity windows and episode-level provenance, for teams that need history rather than similarity search.
Code graphs. Graphify-Labs/graphify parses locally with tree-sitter and explains every edge. Egonex-AI/Understand Anything is the heavier version: our analysis describes it as an MIT-licensed plugin running a multi-agent pipeline over the repository, writing a graph to a JSON file and opening a dashboard to search and question it, and notes the first full run is the part that will surprise you. colbymchenry/codegraph builds a local graph of symbols, call edges and dependencies and serves it to agents over MCP, and our analysis says the pitch is fewer tool calls and less context spent on file discovery, with the README putting its own cost claim on record. DeusData/codebase-memory-mcp indexes into a persistent graph behind a single static binary with 15 tools and a local 3D graph view, and our analysis is direct that the trade-off is real: a native binary that reads your codebase and rewrites your agent config. abhigyanpatwari/GitNexus does the same indexing in the browser, with the analysis noting that the licence is not open source in the usual sense, which is worth settling before you adopt it.
Everything else. AgriciDaniel/claude-obsidian turns local sources into linked, provenance-tracked Markdown pages in a vault you own, which is a knowledge graph without a graph database, and our analysis says the transaction model is careful to the point of friction. xerrors/Yuxi bundles retrieval, knowledge graph extraction, agent orchestration, MCP and skills behind one multi-tenant workspace, and our analysis notes the Docker Compose install is where the real cost starts.
In practice
GraphRAG is the right tool when the answer is a relationship or a property of the whole corpus, and the wrong tool for finding a passage, because it replaces a cheap incremental index with an expensive extract-then-summarise build. Decide which of the three shapes you are building: a community-summarisation index for aggregate questions, a temporal graph for agent memory that changes, or a deterministic code graph for source. Whichever it is, entity resolution is the part that decides the answer quality, the corpus-wide extraction cost is the part that decides whether the project ships, and the maintenance note in microsoft/graphrag's README is a reason to look at the actively developed alternatives before committing to it.