GraphRAG vs Vector RAG: What the Benchmarks Show and What Indexing Costs

Indexing 10,000 documents with Microsoft's GraphRAG on GPT-4.1 costs roughly $722 in model tokens. Embedding the same corpus for plain vector retrieval costs about $2.60. That 278-fold gap is the part of the GraphRAG vs RAG debate that Microsoft's headline benchmark never prices, and it is not even the largest bill. Retrieval augmented generation with a graph wins on one narrow class of question, and you pay for that win every time you rebuild and every time you ask.

The short answer. GraphRAG beats vector RAG on questions that ask what a whole corpus says, such as themes, trends and cross-document patterns. Vector RAG matches or beats it on specific facts. GraphRAG indexing costs roughly 100 to 1,800 times more than embedding, depending on model, and its global queries cost hundreds of times more per question. Choose it for sensemaking workloads only.

What GraphRAG does that vector RAG does not

Vector RAG, the default form of retrieval augmented generation, splits your documents into chunks, turns each chunk into an embedding, and at question time fetches the chunks closest to the question. One embedding call per chunk at build time is the whole index.

GraphRAG adds a knowledge graph between the documents and the model. It asks an LLM to read every chunk and extract entities and relationships, then clusters the resulting graph into communities and asks the LLM again to write a summary report for each community. The index is therefore mostly model-written text, which is why it costs so much more to build.

The indexing pipeline, step by step

The current open-source defaults make the cost structure visible. According to the project's defaults file on GitHub, GraphRAG chunks text at 1,200 tokens with 100 tokens of overlap and extracts four entity types (organisation, person, geography and event). It runs one extra "gleaning" pass that asks the model what it missed. It then writes community reports of up to 2,000 output tokens from up to 8,000 input tokens. The default completion model is gpt-4.1 and the default embedding model is text-embedding-3-large.

Every one of those steps is an LLM call priced at chat-model rates, not embedding rates. The gleaning pass alone means each chunk can be read twice. The repository carries its own warning that "GraphRAG indexing can be an expensive operation" and tells you to start small.

Local search and global search are different products

GraphRAG answers questions in two main modes. Local search starts from entities mentioned in the question and pulls their neighbourhood of the graph plus linked text. Global search reads community reports across the whole corpus and combines partial answers in a map-reduce pass. The benchmarks that made GraphRAG famous are about global search, and global search is also where the query cost sits.

If your users ask "what does clause 14.2 say", neither mode needs a graph. If they ask "what are the recurring complaints across 4 years of support tickets", global search is the only mode that was designed for it.

What Microsoft's GraphRAG benchmark actually measured

The founding paper is "From Local to Global: A GraphRAG Approach to Query-Focused Summarization" by Darren Edge and colleagues at Microsoft Research, revised on arXiv in February 2025. It tested two corpora. Podcast transcripts came to about 1 million tokens in 1,669 chunks of 600 tokens. News articles came to about 1.7 million tokens in 3,197 chunks.

The indexing and answer prompts were designed for GPT-4, and indexing used gpt-4-turbo. Graph indexing of the podcast corpus took 281 minutes. The paper does not report the token cost of indexing anywhere in its results. That omission is reasonable in a research paper, and it is the one that matters most to anyone pricing a deployment.

The headline result is real. Global GraphRAG conditions beat vector RAG on comprehensiveness 72% to 83% of the time on podcasts and 72% to 80% on news, and on diversity 62% to 82% of the time. The authors then cross-checked with a claim-counting method that does not rely on an LLM preference, and the direction held. GraphRAG's root-level answers averaged 34.18 extracted claims per answer on news against 25.23 for vector RAG.

What the paper scoped out

Three things sit outside that result and the authors say so. Vector RAG "produces the most direct responses across all comparisons", so on directness the baseline won. Empowerment, meaning whether the answer helps the reader judge the topic, was mixed. And the evaluation "focused on sensemaking questions specific to two corpora each containing approximately 1 million tokens", in the authors' own limitation section.

The questions themselves were generated to be global. Nobody asked GraphRAG a lookup question in this paper. That is a scope, not a flaw, and the scope disappeared when the result travelled into vendor decks as "GraphRAG beats RAG".

The paper's famous token saving, over 97% fewer tokens per query for root-level summaries, is measured against a map-reduce summary of the entire source text, not against vector RAG. Against vector RAG with an 8,000-token context, GraphRAG global search uses more tokens per query, not fewer.

Independent RAG benchmarks: where GraphRAG wins and loses

Three independent evaluations published since 2025 tested GraphRAG against plain RAG on wider question sets. They disagree on details and agree on the shape: graphs help on multi-hop and summary questions, and plain retrieval holds its ground or wins on facts.

Haoyu Han and colleagues ran a systematic comparison on standard question-answering sets in "RAG vs. GraphRAG: A Systematic Evaluation and Key Insights", revised October 2025. On Natural Questions, a single-hop set, plain RAG scored 64.78 F1 against 54.48 for GraphRAG global search. On MultiHop-RAG with a 70B model, GraphRAG local search led with 71.17 against 65.77 for RAG.

The paper's ugliest number is on questions with no answer in the corpus. Plain RAG correctly handled 96.01% of those null queries with the 8B model. GraphRAG global search managed 19.27%. The authors' summary is that global search "tends to hallucinate in QA tasks", which is a serious property for any system a customer will trust.

Single-fact lookups still favour vector RAG

GraphRAG-Bench, from Zhishang Xiang and colleagues (arXiv 2506.05690, revised February 2026), built a benchmark specifically to ask when graphs earn their keep. Its first observation is blunt: basic RAG is "comparable to or outperforms GraphRAG in simple fact retrieval tasks". On the novel corpus, RAG with a reranker scored 60.92 accuracy on fact retrieval against 49.29 for MS-GraphRAG.

The graph methods did win on complex reasoning. HippoRAG2 scored 53.38 against 42.93 for RAG. It was not Microsoft's GraphRAG that won, and the cheaper graph builders often matched or beat the expensive one. For reranking alone, the evidence in our breakdown of hybrid search and reranker benchmarks suggests you can close part of the gap without building a graph at all.

The LLM judge was part of the result

The most uncomfortable paper for GraphRAG's headline is "How Significant Are the Real Performance Gains?" by Qiming Zeng and colleagues, posted in May 2025. They ran the standard LLM-judge protocol on two identical copies of the same system. A fair judge returns a tie. The answer listed first won 90% of the time.

After swapping answer order, aligning answer length and repeating trials, they report that "LightRAG originally outperforms NaiveRAG with a win rate of 72% vs. 28% but NaiveRAG slightly outperforms LightRAG after eliminating the biases." Across three GraphRAG methods, including Microsoft's, gains were "much more moderate than reported previously". Han and colleagues found the same position bias independently, with judges making "completely opposite decisions depending on the order".

That does not overturn Edge and colleagues, whose claim-counting check pointed the same way. It does mean any vendor win rate for GraphRAG should prompt one question: was the answer order swapped? If you are building your own comparison, the guide to building an LLM eval suite covers how to keep a judge honest.

The GraphRAG indexing cost the benchmarks leave out

None of the four papers above prices an index in dollars. GraphRAG-Bench comes closest. Its Appendix Table 10 reports that MS-GraphRAG spent 535,832 input tokens and 118,841 completion tokens to index one book of approximately 56,000 tokens, in 292 seconds.

That gives a usable ratio. GraphRAG read about 9.6 input tokens and wrote about 2.1 output tokens for every token of source text, roughly 11.7 tokens in total. The output share matters most, because output tokens cost 4 to 8 times more than input on most rate cards.

Vector RAG has no row in that table. You embed each chunk once. With 100-token overlap on 1,200-token chunks you embed roughly 8% more tokens than the corpus contains, at embedding rates that are a small fraction of chat rates. The cost difference is not a matter of tuning. It is two different kinds of computation.

GraphRAG cost model for a 10,000-document corpus

Here is the arithmetic, built only from published rate cards and the GraphRAG-Bench ratio. Prices come from OpenAI's API pricing page and Anthropic's pricing page, both read on 23 October 2026.

Assumptions, stated so you can replace them

The corpus is 10,000 documents of 2,000 tokens each, so 20 million tokens. That is an assumption, not a measurement: a contract archive will run longer, a ticket archive shorter. Indexing consumes 9.57 input and 2.12 output tokens per corpus token, which gives 191.4 million input tokens and 42.4 million output tokens. Embedding the 20 million corpus tokens costs $0.40 with text-embedding-3-small at $0.02 per million, or $2.60 with text-embedding-3-large at $0.13 per million.

Model costs exclude GraphRAG's own embedding step, which embeds the text plus generated descriptions and reports and adds roughly $3 to $8 at text-embedding-3-large rates. Both OpenAI and Anthropic list batch prices at half these rates; GraphRAG's indexer calls the standard endpoint unless you wire batch in yourself. Reasoning models such as gpt-5-nano can bill extra hidden output tokens, so treat that row as a floor.

The default configuration is the expensive one. A team that runs graphrag init, accepts gpt-4.1, and points it at 20 million tokens spends about $722 before asking a single question. Against text-embedding-3-small, the cheapest vector index, that is about 1,800 times more. That range, 278 to 1,800 times, brackets Microsoft's own statement that LazyGraphRAG's indexing costs 0.1% of full GraphRAG, roughly a 1,000-fold difference.

My view is that $722 is not the number that should scare you. It is a rounding error against an engineer's week. What should change your decision is that it is a recurring number. Every time your corpus changes enough to need a rebuild, you pay it again, and a corpus that is worth querying is usually a corpus that keeps growing. The per-query arithmetic in our comparison of inference provider rate cards applies here too: a cheaper host for the same model changes the bill more than any GraphRAG setting.

The GraphRAG query bill is bigger than the index bill

GraphRAG-Bench also measured the average prompt size per question. Vector RAG sent 879 tokens per query on the novel corpus, GraphRAG local search sent 38,707 and GraphRAG global search sent 331,375. Those are per question, every question.

At gpt-4.1's $2.00 per million input tokens, a vector RAG query costs about $0.002 in prompt tokens. A GraphRAG local query costs about $0.08. A global query costs about $0.66. Run 1,000 global queries a month and you spend about $663 a month on prompts alone, which is nearly the full index cost every 5 weeks.

The paper's own text describes global prompts as reaching "up to 4×10^4 tokens", which does not match its figure. At 40,000 tokens, a global query costs about $0.08 and the monthly bill falls to about $80. Edge and colleagues measured 26,657 to 39,770 tokens per root-level global query on their 1 million token corpora. Global search reads community reports, so the prompt grows with the corpus, and a 20 million token corpus will have more communities than any corpus in these papers.

This is the same pattern we found when pricing RAG against long context on a 10,000-document base: the architecture that reads more per question loses on cost at volume, whatever its build cost. GraphRAG global search is, economically, a long-context system with a very expensive preprocessing step.

LazyGraphRAG and the cheaper middle ground

Microsoft Research knows all this. In November 2024 it announced LazyGraphRAG, which defers LLM work until query time. Its claim is that "LazyGraphRAG data indexing costs are identical to vector RAG and 0.1% of the costs of full GraphRAG", with comparable quality to global search "but more than 700 times lower query cost". The test set was 5,590 AP news articles and 100 synthetic queries.

A June 2025 follow-up on the BenchmarkQED tooling went further. Microsoft reported that LazyGraphRAG achieved higher win rates than vector RAG even when vector RAG was given a 1 million token context window holding most of the dataset. The only comparison that failed to reach significance was the relevance of answers to local queries.

Two cautions. These are Microsoft's own numbers, scored with Microsoft's own LLM-judge framework, which is the protocol Zeng and colleagues showed can be biased. And per Microsoft's own editor's note, LazyGraphRAG ships inside Microsoft Discovery and Azure Local services, not as a free download. The LazyGraphRAG configuration that GraphRAG-Bench ran consumed 591,150 tokens to index the same 56,000-token book, barely below full GraphRAG. Whatever that implementation was, it did not reproduce the 0.1% figure, and outside teams cannot easily check the official one.

The GitHub README now also states that the open-source project "is largely in maintenance mode". A maintained fork or a lighter builder such as HippoRAG2, which spent half the tokens of MS-GraphRAG and beat it on reasoning in GraphRAG-Bench, is the more defensible bet for a new build.

Where this argument is weakest

The cost model above rests on one measurement of one book. Know how thin that is before you repeat the $722 figure.

The token ratio is borrowed, not measured on your data

The 11.7-tokens-per-token ratio comes from a 56,000-token novel indexed under GraphRAG-Bench's configuration, which may not match today's defaults for chunk size, gleanings or prompts. Dense technical text produces more entities per chunk than fiction. Edge and colleagues note that "using larger chunk size is less costly in terms of calls to the LLM", and the default chunk size has doubled since their paper. Your real ratio could be half this or double it.

The query-token figures carry a worse problem: GraphRAG-Bench's text and figures disagree by roughly 8 times on global search. I have shown both and built the chart on the larger one, which favours my argument. A reader who prefers the smaller figure would conclude the query bill and index bill are similar in size after a year, which is a materially weaker version of the claim.

The case that the money is irrelevant

The strongest counter-argument is that none of these sums matter. Even the worst case here, about $8,700 a year, is less than one month of one engineer's salary in most markets. If GraphRAG global search answers a question your analysts would otherwise spend a day on, it pays for itself on the first query. On that view, comparing it with vector RAG on cost misses the point.

I think that argument is correct for a small team asking a few hundred sensemaking questions over a stable corpus. It fails for customer-facing products, where query volume scales with users and the null-query hallucination rate becomes a support problem. The decision is not about the size of the bill. It is about whether your questions are the kind GraphRAG wins on, and the evidence says most production questions are not.

Frequently asked questions

Where to start before you build a graph

Pull 200 real questions from your logs or your users and label each one: does it ask for a fact, or for a pattern across many documents? If fewer than 1 in 5 are pattern questions, build vector RAG with a reranker and stop there. The graph is solving a problem you do not have.

If the pattern questions dominate, index a 1% sample of your corpus with a mini model and read the token count off the run. Multiply by 100, then multiply your expected monthly global queries by the prompt size you observe. That one afternoon replaces every number in this post with your own, the only version worth taking to a budget meeting.

Related reading