—
total indexing cost (one-time)extraction cost (before overhead)
—chunks processed
—per 1M source tokens
Total indexing cost by corpus size
Same chunk size, prompt overhead and overhead share as above, swept across corpus size — this is how a "$33 test corpus" becomes a "$3,300 production corpus." The right-hand column shows the same sweep at a budget-tier extraction model ($0.15 / $0.60 per 1M) to show how much of the bill is model choice rather than corpus size.
| Corpus size | Chunks | Extraction cost | Total indexing cost | At budget-tier model |
|---|
Budget-tier column re-runs the same chunk math at $0.15 input / $0.60 output per 1M tokens — a cheaper extraction model cuts the bill roughly in proportion to the price drop, not the corpus size.
One-time indexing vs. recurring query cost
Indexing happens once per corpus version. Query cost happens on every single question, forever — GraphRAG adds the row below on top of it, not instead of it.
| Cost | When it's paid | Modeled by |
|---|
| GraphRAG indexing (entity/relationship extraction) | Once per corpus version — re-run only when source docs change | This calculator |
| Standard RAG query (retrieval + generation) | Recurring — every question, every user, forever | RAG Cost Calculator |
| GraphRAG query (graph traversal + generation) | Recurring, same as standard RAG query cost — paid in addition to indexing | RAG Chatbot Cost Calculator |
How this connects to other RAG tools
This page only prices the indexing half of GraphRAG — the one-time LLM pass that turns your documents into a knowledge graph. It doesn't replace the tools that price everything downstream of that. Once the graph exists, every question against it still costs retrieval plus generation, same as any other RAG system — price that recurring side on the RAG Cost Calculator or, for a chat-style interface with conversation history, the RAG Chatbot Cost Calculator. If you're still deciding whether a knowledge graph is the right architecture at all versus fine-tuning a model on your corpus instead, RAG vs Fine-Tuning lays out that trade-off. And because the underlying vectors — for chunk embeddings and community summaries — still need somewhere to live, check what that storage costs on the Vector Database Cost Calculator.
How this calculator works
The GraphRAG Indexing Cost Calculator works forward from chunking. Your corpus size divided by chunk size, rounded up, gives the number of chunks the extraction LLM has to process — a 1,000,000-token corpus at 1,200 tokens per chunk is 834 chunks. Each chunk's input to the model is the chunk itself plus the extraction prompt overhead — the instructions and JSON schema that tell the model what to extract — and each chunk produces extraction output tokens of entities, relationships and claims. Multiplying input and output tokens by their respective per-1M prices and summing across all chunks gives the raw extraction cost. Real GraphRAG pipelines also spend on community summarization (turning clusters of entities into higher-level summaries) and on embedding the graph's text for retrieval, so the non-extraction overhead share grosses the extraction cost up to a total indexing cost — at the 25% default, extraction is roughly three-quarters of the bill.
The number that moves the result most is which model does the extraction. Token counts per chunk barely change between implementations, but price per token can differ by ten to twenty times between a frontier model and a budget tier, and that difference passes straight through to the total. Corpus size moves the total roughly linearly — a 10x bigger corpus costs roughly 10x more to index, which is the whole story behind the "$33,000 vs $33" reports: same architecture, wildly different corpus size and model choice. And critically, this is a one-time cost per corpus version — it's paid once when you build or rebuild the graph, not on every query, unlike the retrieval-and-generation cost that recurs on every question against the system. Reference estimates from published GraphRAG and LightRAG pricing patterns; actual cost depends on your prompt, schema and implementation.
What does GraphRAG indexing actually do that standard vector RAG doesn't?
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.
Why do real-world GraphRAG cost estimates vary by 100x or more between different reports?
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.
Is GraphRAG indexing a one-time cost or does it keep recurring?
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.
When is GraphRAG's indexing cost actually worth paying?
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.