GraphRAG earns its reputation on multi-hop and whole-corpus questions, and earns its other reputation on the indexing invoice. A naive full-corpus run, LLM entity extraction, relationship extraction, and community summarization over every chunk, can cost more than a year of query traffic before answering a single question. This is the pipeline design we use to get graph-level answer quality at a fraction of that bill.
Why does GraphRAG indexing get so expensive?
Because standard GraphRAG makes multiple LLM passes over every chunk of the corpus, entity extraction, relationship extraction, optional claim extraction, then LLM-written summaries for every detected community, so cost scales with corpus tokens multiplied by passes. Vector indexing pays cheap embedding rates; GraphRAG pays generation rates, typically 10x to 100x more per token.
Rough math for a 2 GB text corpus: roughly 500 million tokens of input, each chunk processed with a long extraction prompt, plus gleaning re-passes where the model is asked what it missed, plus one generated report per community across several hierarchy levels. Even at mid-tier model pricing this typically lands in the thousands of euros, and you pay it again on every full re-index. The cost drivers, in order:
- ▸Extraction passes dominate: every chunk goes in, structured entities and relations come out, and output tokens bill higher than input.
- ▸Gleanings multiply it: each configured re-pass adds another near-full traversal of the corpus.
- ▸Community summaries add a second generation phase: Leiden clustering finds communities, then an LLM writes a report for each one, at every level of the hierarchy.
Do you actually need a graph at all?
Build the graph only when a fixed eval set proves vector retrieval fails: multi-hop joins across documents, corpus-wide aggregation questions, or entity disambiguation. A tuned hybrid baseline, dense vectors plus BM25 plus a reranker, answers most enterprise question types; if it passes your eval, the cheapest GraphRAG pipeline is none.
We covered the decision evidence in GraphRAG vs Vector RAG: When Knowledge Graphs Actually Improve Accuracy (2026 Evidence), and the baseline tuning that must come first in RAG Retrieval Quality at Scale: Fixing the Real Bottleneck. The short version: label 50 to 100 real user questions by type. If under roughly 10% are genuinely multi-hop or aggregate, a routed architecture, described below, beats indexing everything into a graph.
How do you shrink the corpus before any LLM sees it?
Scope extraction to the entity-rich fraction of the corpus, which is typically a minority of it. Route by document type, deduplicate near-copies with MinHash or SimHash, strip boilerplate, and never extract from text what you already hold as structured data, your ERP, CRM, and ticketing systems are pre-built entity-relation stores.
- ▸Route by type: contracts, incident reports, meeting notes, and research papers are graph-worthy; changelogs, templates, and generated boilerplate are not.
- ▸Dedupe first: near-duplicate detection routinely removes a meaningful slice of enterprise corpora, and every duplicate chunk is a duplicated extraction bill.
- ▸Mine structure you own: load database rows and API objects into the graph directly as nodes and edges. Zero LLM tokens, and higher precision than any extraction prompt.
- ▸Chunk for extraction, not only retrieval: oversized chunks waste prompt context on low-density text; keep entity density high per chunk.
Which extraction strategy cuts the LLM bill most?
Move extraction off the frontier model. Constrained entity-relation extraction is a task where small models, the GPT-4o-mini and Claude Haiku class, or self-hosted Qwen and Gemma, typically perform close to frontier quality at a fraction of the price. Add a cheap NER pre-filter, constrain outputs to a JSON schema, cap gleanings, and batch everything.
- ▸NER pre-pass: GLiNER or spaCy flags chunks containing entity types of interest for cents; chunks with nothing to extract never reach an LLM.
- ▸Schema-first extraction: define the entity and relation types you will actually query, and force structured output. Open-vocabulary extraction inflates both cost and graph noise.
- ▸Cap gleanings at zero or one: repeated what-did-you-miss passes are the classic silent cost multiplier in default configurations.
- ▸Batch and cache: provider batch APIs are typically around half price for offline work, and prompt caching makes the shared extraction preamble nearly free across millions of chunks.
- ▸Self-host when residency or volume demands it: for EU data residency or very large corpora, a self-hosted Qwen or Gemma on a single GPU node turns extraction into a fixed cost instead of a metered one.
What does lazy, query-time summarization change?
LazyGraphRAG-style designs skip pre-computed community summaries entirely: build a lightweight graph from cheap NER and co-occurrence at index time, then spend LLM tokens only at query time, and only for queries that need graph reasoning. Microsoft has reported indexing costs near 0.1% of full GraphRAG for this pattern; treat exact figures as vendor benchmarks, but the direction is well established.
The design shift is where money is spent: indexing becomes almost free (embeddings plus NER), and the expensive summarization happens per query over just the relevant subgraph, amortized across actual usage instead of paid upfront for communities nobody ever asks about. The trade-off is higher and more variable latency and cost on global questions: acceptable when those are a minority of traffic, painful if they dominate. A middle path that works in production: lazy by default, plus pre-computed summaries only for the top communities your query logs actually hit.
Where should the graph and vectors live?
Start with the database you already run. Postgres holds both sides for most teams: pgvector for embeddings, and either plain edge tables or Apache AGE for the graph. Reach for a dedicated engine, Neo4j, Memgraph, Kuzu, FalkorDB, when traversals go deep, concurrency is high, or the graph passes a few million edges.
Adding a graph database to a stack that has never operated one is a real cost line: another system to secure, back up, and upgrade. Recursive CTEs over an edges table handle two-to-three-hop traversals on modest graphs fine, and embedded engines like Kuzu give you graph query power without running a server. The same keep-it-boring reasoning we laid out in pgvector or a Dedicated Vector Database? A Production Guide applies to the graph side.
How do you keep the index fresh without re-billing the corpus?
Never full re-index. Content-hash every chunk, extract only chunks whose hash is new, upsert entities by canonical ID, and cache extraction outputs keyed by chunk hash plus prompt version plus model version, so re-runs become cache hits. Re-cluster and refresh summaries incrementally on a schedule, not on every commit.
- ▸Idempotent extraction: with cache keys of chunk hash, prompt version, and model version, changing a prompt re-bills only the work the change actually invalidates.
- ▸Entity resolution as a separate cheap stage: merge duplicate entities with embedding similarity plus deterministic rules; reserve LLM adjudication for the genuinely ambiguous cases.
- ▸Scheduled community refresh: nightly or weekly incremental Leiden runs over subgraphs touched by changed chunks keep summaries current at a bounded cost.
How do you prove the graph is earning its cost?
Track cost per correctly answered query by question type, not indexing cost in isolation. Keep a fixed eval set split into single-hop, multi-hop, and aggregate questions; measure the vector baseline against the graph path on each type; and route in production so only graph-shaped queries pay the expensive path.
If the graph wins on 8% of traffic, it should serve roughly 8% of traffic: a small classifier or the agent's own routing sends multi-hop and aggregate questions to the graph path and everything else to the hybrid vector path. That keeps the accuracy gains while holding token spend close to the vector-only baseline. Budgeting the query side uses the same discipline as any inference workload, see AI Inference FinOps in 2026: A Playbook to Stop Overpaying per Token. Whatever eval framework you use, validate the judge against a hand-labelled sample before trusting its verdicts on retrieval quality.
How TuniCyberLabs helps
We design and build RAG and GraphRAG systems for EU and North African companies with the cost model as a first-class requirement: scoped extraction, small-model pipelines, EU-resident self-hosted options, and eval harnesses that prove the graph earns its keep before it scales. If your GraphRAG pilot produced a great demo and a frightening invoice, our engineering team can redesign the pipeline around your actual query mix.