GraphRAG Guide: When Knowledge Graphs Beat Vector RAG (and When They Don't)
GraphRAG is not dead, but it is not the default either. microsoft/graphrag shipped v3.1.1 on 2026-07-18 to 35,088 GitHub stars, and three 2026 benchmark papers now report, out loud, that it frequently loses to plain vector retrieval. So this GraphRAG guide answers the only question left: is a knowledge graph worth the indexing bill?
Should You Use GraphRAG? The Short Answer
Use GraphRAG when your questions cross entities or span the whole corpus, like "which suppliers does our biggest customer also sell to?" Stick with vanilla or hybrid RAG for single-hop fact lookups, fast-changing documents, and tight latency budgets. The graph pays for itself on multi-hop questions and costs money everywhere else.
GraphRAG is not dead and it is not the default. It earns its indexing bill when your questions are multi-hop or corpus-global, and it loses money when they are not.
The short version:
- GraphRAG wins on multi-hop and corpus-wide questions; vanilla RAG wins on single-hop lookups.
- The 2026 benchmarks are mixed: graphs help aggregation but can hurt fine-grained summarization.
- The cost lands at index time, in LLM extraction calls, not at query time.
- Run Basic Search as a control on your own corpus before you build anything.
If you already run a working vector RAG pipeline, the only decision is whether a graph on top earns its keep. The table below is the whole argument in six rows, and where it says stay on vanilla, that is the honest answer, more often than the vendors admit. Hybrid BM25 plus vector retrieval covers most of these cases without a graph at all.
| Your situation | Vanilla / hybrid RAG | GraphRAG | Why |
|---|---|---|---|
| Single-hop fact lookup ("what's the refund window?") | Yes | No | A top_k window over BM25 plus vectors already answers this; the graph adds latency and cost |
| Multi-hop entity questions ("which suppliers does our biggest customer also sell to?") | No | Yes | Graph traversal connects entities that never share a chunk |
| Corpus-wide thematic questions ("what themes recur across 4,000 tickets?") | No | Yes | Community summaries aggregate across the whole document set |
| Compliance and explainable-provenance requirements | Partially | Yes | Edges give an auditable path from answer back to source |
| Fast-changing corpus (documents updated weekly) | Yes | No | Re-indexing a graph on every update is expensive; vectors re-embed cheaply |
| Tight latency or indexing-cost budget | Yes | No | Extraction calls make indexing slow and costly before any query runs |
What GraphRAG Actually Is: From Chunks to Communities
GraphRAG is retrieval-augmented generation over a knowledge graph instead of over disconnected chunks. At index time an LLM extracts entities and relationships from your documents, the Leiden algorithm groups those entities into communities, and each community gets a summary. At query time the graph plus those summaries answer questions that a top_k window over chunks structurally cannot.
The pipeline, end to end:
Documents
|
v
Chunks --> LLM entity + relationship extraction
|
v
Knowledge graph (entities = nodes, relations = edges)
|
v
Leiden community detection --> community summaries
|
v
Vector index over entity + community descriptionsTwo phases do the work. The indexing phase is the expensive one: every chunk costs an LLM call to pull out entities and relationships, and the community summaries cost more calls on top. The query phase is where the payoff shows up. Because the graph stores relationships explicitly, a question like "which suppliers does our biggest customer also sell to?" becomes a traversal instead of a hope that the right two chunks land in the same top_k window.
The summaries matter because they are what Global Search actually reads: corpus-wide questions get answered from pre-written community prose, not raw chunks. And every edge is an LLM judgment call, stored as a triple you could query in Cypher on a real graph database. That design is also why indexing dominates the cost, which the numbers below make concrete.
The framing that earns its place: vanilla RAG retrieves passages, and GraphRAG retrieves structure. Your choice of embedding model still matters for the vector layer, and your vector database still stores the descriptions, but the graph is the new load-bearing piece. The official Index Overview docs describe each stage in full.
What Are the Four GraphRAG Query Methods?
The GraphRAG query engine ships four methods: Local Search, Global Search, DRIFT Search, and Basic Search. Local Search reasons outward from specific entities, Global Search aggregates community summaries across the whole corpus, DRIFT Search blends the two recursively, and Basic Search is a plain vector baseline. A fifth feature, Question Generation, sits on top of the engine rather than alongside it.
We checked the live docs at microsoft.github.io/graphrag/query/overview/ on 2026-07-30, and the count is four. Most ranking guides name two or three. The same check found the word "lazy" zero times on both the Index and Query overview pages, which matters for the cost section below.
| Method | What it answers | Cost profile | Use it when |
|---|---|---|---|
| Local Search | Entity-centered questions ("what does Acme own?") | Medium; pulls entity and neighbor context | Multi-hop questions anchored to known entities |
| Global Search | Corpus-wide themes ("what are the main complaint types?") | High; fans out over community summaries | Aggregation across the whole document set |
| DRIFT Search | Hybrid queries needing local depth and global breadth | Highest; recursive drift steps | Complex questions where Local alone loses context |
| Basic Search | Single-hop fact lookups | Lowest; plain vector retrieval | The control you A/B the graph against |
The row worth your attention is the last one. Basic Search is the built-in vanilla-vector baseline, and it exists so you can A/B the graph against plain retrieval on your own corpus and find out whether the graph is earning its bill. That is not trivia; it is the whole decision procedure of this guide in one feature. Run Basic Search first. If Local, Global, or DRIFT search does not beat it on the questions you actually get asked, the graph is a cost, not an upgrade.
What Did the 2026 Benchmarks Actually Find?
Three 2026 benchmark papers find that GraphRAG helps on multi-hop and multi-fact aggregation tasks but frequently underperforms vanilla RAG elsewhere. One of them builds a benchmark specifically to find where graphs lose. All three agree the win depends on question type, not on corpus size. The evidence says GraphRAG is situational, not default.
| Paper | Date | What it found |
|---|---|---|
| arXiv:2506.05690, When to use Graphs in RAG | v3 revised 2026-02-22 | Recent studies report graph pipelines frequently underperform vanilla RAG on real-world tasks; the authors build GraphRAG-Bench to identify where they do not |
| arXiv:2602.02053, WildGraphBench | 2026-02-02 | 1,100 questions across 12 topics; graphs help multi-fact aggregation from a moderate number of sources but favor high-level statements and weaken fine-grained summarization |
| arXiv:2502.11371, RAG vs. GraphRAG: A Systematic Evaluation | v3 revised 2026-03-04 | Unified protocol across QA and query-based summarization; each paradigm has distinct strengths, and strategies combining both outperform either alone |
A fourth effort, GraphRAG-Bench (repository), evaluates nine GraphRAG methods across 16 disciplines and 20 textbooks, and reaches the same conclusion from a wider angle.
All three papers converge on one point: the graph earns its cost on multi-hop aggregation and loses it on fine-grained recall.
Our read: the hype cycle did the damage, and these papers are the correction. None of them says graphs are useless. What they say, consistently, is that the aggregation step that makes GraphRAG good at corpus-wide themes is the same step that blurs fine-grained detail. WildGraphBench is the clearest example: graphs helped multi-fact aggregation from a moderate number of sources, and hurt summarization precision in the same evaluation. That is not a contradiction; it is one mechanism showing up twice.
The practical consequence is that you cannot decide this from the literature alone. The papers tell you which question types to test, not whether your corpus is one of them. That is exactly what the Basic Search control from the methods section above is for.
How Much Does GraphRAG Cost? (And the LazyGraphRAG Caveat Everyone Repeats Wrong)
GraphRAG's cost is an indexing-time bill, not a query-time one, which is exactly why it surprises people. The LLM calls that extract entities and relationships from every chunk, plus the community summarization pass, are what make it expensive. You pay up front, before a single query runs. Query time is cheaper but not free: Global Search fans out over community summaries with an LLM call per community, which is why the methods table above marks it high.
The only hard public numbers come from Microsoft Research. On 2024-11-25 the team reported that LazyGraphRAG's indexing cost was identical to vector RAG and 0.1% of the cost of full GraphRAG, and that at 4% of the query cost of GraphRAG global search it outperformed the competing methods tested, on both local and global query types (Microsoft Research). Those are Microsoft's figures, from Microsoft's blog, and we report them as such; we have not run a priced index of our own.
Here is the correction most write-ups miss. LazyGraphRAG is not a pip install option. Per Microsoft's own editor's note of 2025-06-06, it shipped into Microsoft Discovery and Azure Local, not into the open-source package. We checked the official Index Overview and Query Overview pages on 2026-07-30: the word "lazy" appears zero times on both. So if a guide lists LazyGraphRAG as a variant you can spin up this afternoon, it is repeating a claim that stopped being true in the open-source world.
What you can do today: run the extraction model locally. Pointing the indexing step at a local model through Ollama removes per-token API fees from the most expensive phase, and pairing it with a self-hosted vector store keeps the rest of the bill near zero.
Which GraphRAG Library Is Actually Maintained?
Two of the six most-cited GraphRAG libraries have not had a push in six and nine months. We pulled these figures from the GitHub API on 2026-07-30, and the census below is the check older round-ups skip, with the command to re-run it before you commit to one. LightRAG and microsoft/graphrag are the active ones; nano-graphrag and fast-graphrag are drifting toward abandonware.
| Library | Stars | Last push | Open issues | Read |
|---|---|---|---|---|
| HKUDS/LightRAG | 38,353 | 2026-07-30 | 217 | Most active; large issue backlog |
| microsoft/graphrag | 35,088 | 2026-07-26 | 61 | Reference implementation; v3.1.1 released 2026-07-18 |
| getzep/graphiti | 29,377 | 2026-07-30 | 438 | Temporal-graph angle; heavy backlog |
| neo4j/neo4j-graphrag-python | 1,237 | 2026-07-27 | 30 | Small, tidy, vendor-maintained |
| gusye1234/nano-graphrag | 3,949 | 2026-01-27 | 84 | About six months since last push |
| circlemind-ai/fast-graphrag | 3,834 | 2025-11-01 | 38 | About nine months since last push |
for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; doneOur read: stars are a vanity metric; the push date is the number that matters. LightRAG and microsoft/graphrag are both actively maintained, with Graphiti close behind on a temporal-graph angle. nano-graphrag and fast-graphrag are the two that older posts still recommend on reputation alone, and neither has shipped in half a year.
How to choose: pick microsoft/graphrag if you want the reference implementation with the four official query methods, LightRAG if you want the most active project and a lighter footprint, and a vendor-maintained library like neo4j-graphrag-python if you already run that vendor's database. Avoid anything whose last push predates your project by half a year.
Graphiti deserves one scoped note: its temporal-graph design is built for retrieval over time-aware data, and it overlaps with agent memory, which we cover separately in our guide to Graphiti and temporal graph memory. For the wider field, see the wider RAG tooling landscape.
What Breaks After Day 200: Graph Drift and Re-Extraction
Graph drift is the tax you pay after launch, and it is the number-one practitioner objection for a reason. Every tutorial treats the graph as a thing you build once. Real teams get stuck on day 200.
Three things decay. First, re-indexing on document updates. When 40 documents change, you cannot just re-embed them; you have to re-run LLM extraction on the changed chunks, reconcile the new entities against the old graph, and recompute the affected communities and their summaries. One Medium guide calls incremental update easy. The practitioners on r/Rag disagree. The OP of a 2026-04-25 thread running BM25 plus BGE-M3 over about 600 documents put it plainly: "LLM-based entity/relation extraction is noisy, and re-indexing on doc updates looks painful."
Second, entity-resolution decay. "Acme Corp", "Acme", and "ACME Corporation" arrive in different documents months apart and split into three nodes that should be one. Nothing merges them automatically.
Third, relationships that were true at extraction time and quietly stopped being true. Nobody gets an alert when a reports_to edge goes stale.
def on_documents_changed(changed_docs):
stale = find_affected_nodes(changed_docs)
re_extract(changed_docs)
reconcile_entities(stale)
recompute_communities(affected_only=True)
re_summarize(affected_communities)A codebase is the worst case, and the most interesting one. Autocomplete now surfaces "graphrag for codebase", "graphrag claude code", and "graphrag mcp server", and a codebase is a graph that changes hourly: every commit rewrites call edges, moves symbols, and deletes functions. That is graph drift on a schedule no nightly re-index can fully track. It is also why the serious code-graph tools lean on deterministic parsers such as tree-sitter and LSP for the edges and reserve the LLM for the prose around them: docstrings, commit messages, review threads. If you are graphing a repo, graph the slow-moving layer with the LLM and the fast-moving one with a parser.
What Do Developers Actually Say About GraphRAG?
Working developers are split, and Google seems to know it: a Reddit thread ranks position two on "graphrag vs rag", which is the search engine telling you this topic wants peer opinion, not vendor copy.
The skepticism is real. On r/Rag's 2024 thread "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 points, 86% upvoted), u/EncartaIt wrote: "All of the tutorials I've found are overly simplistic and don't really make a strong case for the knowledge graph pattern." u/Prestigious_Run_4049 was blunter: "I think graph rag is just hype. People love talking about it and it sounds cool but nobody actually uses it in real use cases." Not everyone agrees. u/pytheryx, arguing from production, noted that graph retrieval wins on list-type questions needing context from more chunks than top_k returns; his whitepaper corpus needs around 50 chunks for a complete answer.
The 2026 thread is more measured. u/Popular_Sand2773: "Most graph rag setups just cheat at scale. You run a standard vector or metadata search to find seed nodes then you walk around." u/ggone20, running a roughly 300-million-artifact system: "At scale you literally can't live without them to answer real questions."
Our read matches the sharpest argument in both threads: the inflection point is the complexity of your questions, not the size of your corpus. That is also what the benchmarks above found, which is why we side with the practitioners who scope the tool to multi-hop work rather than the ones who call it dead.
How Techsy Approaches This
Here is the sequencing we use on client builds, and it is deliberately boring.
First, prove the ceiling of hybrid retrieval. Most "we need a graph" requests we hear are actually a chunking or a reranking problem in disguise. A BM25-plus-vector pipeline with a decent reranker answers more than teams expect.
Second, run Basic Search as the control on your own corpus before you build anything. That is exactly what the fourth query method is for: a plain-vector baseline you can A/B the graph against, on your data, with your questions.
Third, only build the graph when a measured class of questions fails that control. If multi-hop or corpus-wide queries miss, you have a real case. If they do not, you just saved yourself an indexing bill and a drift problem.
Want a second set of eyes on your retrieval stack? Get a free consultation.
Frequently Asked Questions
How does GraphRAG work?
GraphRAG indexes your documents into a knowledge graph. An LLM extracts entities and relationships from each chunk, the Leiden algorithm clusters those entities into communities, and each community gets a summary. At query time the engine searches the graph and those summaries, so it can connect facts that sit in different chunks.
How is GraphRAG different from RAG?
Standard RAG retrieves the top-k most similar chunks and feeds them to the model. GraphRAG retrieves structure: entities, the relationships between them, and pre-written community summaries. That extra structure is what lets it answer multi-hop and corpus-wide questions, and it is also what makes indexing slower and more expensive.
When should I use GraphRAG?
Use it when your questions cross entities or span the whole corpus, like supplier-overlap questions or recurring-theme analysis over thousands of documents. Skip it for single-hop fact lookups, fast-changing corpora, and tight latency or cost budgets. If a plain hybrid pipeline already answers a question class, the graph adds cost without adding value.
Is GraphRAG dead?
No, but it is not the default either. The 2026 benchmarks show it frequently underperforms vanilla RAG on everyday tasks, which killed the hype, while still winning on multi-hop and aggregation questions. The honest framing is situational: GraphRAG earns its cost for the right question types and loses money for the rest.
What are the GraphRAG query methods?
The official query engine ships four: Local Search for entity-centered questions, Global Search for corpus-wide aggregation, DRIFT Search for a recursive blend of both, and Basic Search for plain vector retrieval. A fifth feature, Question Generation, sits on top. Basic Search matters most: it is the control you A/B the graph against.
How much does GraphRAG indexing cost?
The cost lands at index time, in the LLM calls that extract entities and relationships from every chunk plus community summarization. Microsoft Research reported LazyGraphRAG indexing at 0.1% of full GraphRAG's cost and identical to vector RAG, but that variant shipped to Microsoft products, not the open-source library. We have not run a priced index ourselves.
Can I run GraphRAG locally with Ollama?
Yes. The microsoft/graphrag library lets you point indexing and querying at a local model served by Ollama, which removes per-token API fees from the extraction step. You trade speed and quality for cost: local models are weaker at entity extraction, so expect noisier graphs and longer index runs on modest hardware.
Is LightRAG or Microsoft GraphRAG better?
They optimize for different things. LightRAG (38,353 stars, pushed 2026-07-30) is the most active and lighter to run; microsoft/graphrag (35,088 stars, v3.1.1) is the reference implementation with the four official query methods. Pick LightRAG for an efficient production graph, Microsoft's for spec-faithful behavior and the Basic Search control.
Who created GraphRAG and when?
Microsoft Research created GraphRAG. The team published the paper in 2024 and maintains the open-source microsoft/graphrag repository under the MIT license, with documentation at microsoft.github.io/graphrag. The reference library reached v3.1.1 on 2026-07-18, and an active ecosystem of third-party implementations, including LightRAG and Graphiti, has grown around it.
The Verdict: When a Graph Earns Its Cost
The evidence points one direction, so here is the position.
- GraphRAG is not dead. It is situational, and the 2026 benchmarks say so out loud.
- It earns its indexing bill on multi-hop entity questions and corpus-wide aggregation. It loses money on single-hop lookups.
- The cost is an index-time bill, and the cheap variant everyone quotes, LazyGraphRAG, never reached the open-source library.
- The graph decays after launch: entity resolution drifts and relationships go stale, so budget for re-indexing.
- Run Basic Search as a control on your own corpus before you build anything.
One sentence: a knowledge graph earns its cost when your questions are multi-hop or corpus-global, and not before. If you want a second opinion on your retrieval stack, get a free consultation.