Question 1

What does GraphRAG indexing actually do that standard vector RAG doesn't?

Accepted Answer

Standard RAG's ingestion step is cheap: split documents into chunks, embed each chunk once with a lightweight embedding model, and store the vectors. There's no LLM call that reads and reasons about content beyond that single embedding pass. GraphRAG replaces that light touch with a genuinely expensive one: an LLM reads every chunk and is asked to extract named entities, the relationships between them, and short claims or descriptions, then those extractions get merged and deduplicated into a knowledge graph, and often summarized again at the community level so the graph can answer 'what are the big themes' questions. That extraction pass is a full LLM completion per chunk — a real prompt with instructions and a schema, a real generation with structured JSON output — repeated across every chunk in the corpus, not a cheap embedding call. For a million-token corpus split into roughly 1,200-token chunks, that's 800-plus separate LLM calls before a single user has asked a single question. This is the cost this calculator isolates: it doesn't exist in vector RAG at all, and it's why teams that assume 'RAG is cheap' get an unpleasant surprise the first time they point GraphRAG at a real document set instead of a demo folder.

Question 2

Why do real-world GraphRAG cost estimates vary by 100x or more between different reports?

Accepted Answer

Because the two knobs that matter most — which model does the extraction, and how much you ask it to extract per chunk — aren't standardized, and every implementation picks them differently. Microsoft's original GraphRAG reference implementation was built to showcase rich extraction: multi-hop relationships, detailed claims, generous output budgets, run against frontier-class models, and it costs accordingly. Community forks like LightRAG and nano-graphrag were built explicitly as a reaction to that cost, using lighter prompts, smaller output schemas, and cheaper models, and they land an order of magnitude or more below it for a similar corpus. Swap a frontier extraction model for a budget tier — something like $0.15/$0.60 per million tokens instead of $2.50/$10 — and the bill drops roughly proportionally, because token counts per chunk barely change while price per token falls five to fifteen times. Add to that the fact that reports rarely state their chunk size, prompt overhead, or whether they're counting community-summarization and embedding costs on top of raw extraction, and two 'GraphRAG cost' numbers for a similar-sized corpus can legitimately differ by two orders of magnitude without either one being wrong. If you see a headline number without the model name and chunk size next to it, treat it as unverifiable and rebuild it with your own assumptions using a calculator like this one.

Question 3

Is GraphRAG indexing a one-time cost or does it keep recurring?

Accepted Answer

It's one-time per version of your corpus, not one-time forever, and that distinction matters. You pay the extraction cost once to build the graph from a given snapshot of source documents, and you don't pay it again unless those documents change — add new documents, edit existing ones significantly, or want a periodic refresh, and you re-run indexing on what changed. That's fundamentally different from query cost, which is standard RAG's real recurring expense: every single question a user asks triggers a fresh retrieval and a fresh generation call, forever, scaling directly with usage. GraphRAG doesn't replace that recurring query cost — it adds the extraction cost on top of it. You still pay for retrieval and generation on every query against the graph, same as you would with plain vector RAG, plus you paid the one-time indexing bill up front. So the honest way to think about total cost of ownership is indexing-cost-once plus query-cost-times-every-question-forever, and for a system that gets heavy sustained traffic, the query cost dwarfs the indexing cost over any reasonable time horizon — the indexing bill just front-loads a chunk of spend before the system has answered a single real question, which is exactly the number that catches people off guard when they weren't expecting it.

Question 4

When is GraphRAG's indexing cost actually worth paying?

Accepted Answer

When your queries genuinely need to traverse relationships across many documents rather than retrieve a single relevant passage. Questions like 'what are the major themes across this entire document set' or 'how are these three organizations connected across our filings' are exactly what plain vector similarity search handles badly — it retrieves passages that are semantically close to the question, but it has no concept of an entity appearing in twenty different documents or a relationship spanning three hops, so it either misses the connection entirely or requires the LLM to stitch it together from disconnected chunks at query time, badly. That's the query pattern GraphRAG's knowledge graph exists to serve, and it's worth the upfront extraction spend if that pattern is a meaningful share of your real usage. If your actual traffic is mostly single-document lookup — 'what does section 4.2 of this contract say' — standard vector RAG answers it just as well for a fraction of the cost, no graph required, and the extraction spend modeled on this page is money spent building infrastructure nobody's queries will ever use. Test the query pattern before committing to the indexing bill: run a sample of real user questions against plain RAG first, and only reach for GraphRAG once you can point to specific multi-hop, whole-corpus questions that plain retrieval is provably failing to answer.

Kosten	Wenn es bezahlt ist	Modelliert von
GraphRAG-Indizierung (Entitäts-/Beziehungsextraktion)	Einmal pro Korpusversion – nur erneut ausführen, wenn sich die Quelldokumente ändern	Dieser Rechner
Standard-RAG-Abfrage (Abruf + Generierung)	Wiederkehrend – jede Frage, jeder Benutzer, für immer	RAG-Kostenrechner
GraphRAG-Abfrage (Graphdurchquerung + Generierung)	Wiederkehrende Kosten wie bei Standard-RAG-Abfragen – zusätzlich zur Indizierung bezahlt	RAG Chatbot-Kostenrechner

GraphRAG-Indizierungskostenrechner

Gesamtkosten für die Indexierung nach Korpusgröße

Einmalige Indizierung im Vergleich zu wiederkehrenden Abfragekosten

Wie dies mit anderen RAG-Tools verbunden ist

So funktioniert dieser Rechner