When GraphRAG earns its indexing cost

The constraint. GraphRAG's cost sits almost entirely in construction, and construction scales with corpus size times extraction model price. Entity and relationship extraction runs per chunk, then community detection and summarization run over the result — several model calls per chunk, not one. The benefit only materialises on queries that actually traverse a relationship.

The number that decides it is not in the question. What fraction of the query log is genuinely multi-hop? Sample 500 real queries and classify them. In most enterprise corpora it lands between 5% and 15%. Paying $180,000 to improve 10% of traffic, when the other 90% gets no benefit and the index now has to be rebuilt on every corpus change, is a poor trade. Route the multi-hop slice to a graph and leave the rest on vector retrieval.

Cheaper things that capture most of the benefit.

1. 01Check whether the graph already exists. If entities are columns in a relational store, you have a graph and it is called a foreign key. LLM extraction to rediscover relationships you already model is the most expensive way to obtain data you own.
2. 02Parent-child and document-hierarchy links. A large share of "multi-hop" is really "this section refers to that section." Structural links are free at ingest time.
3. 03Query-time extraction instead of index-time. Retrieve broadly, extract entities over the retrieved set, expand once. Costs a round trip per query rather than $180,000 once, and it never goes stale.

The recurring cost people omit. Rebuild economics. At 2% daily churn a full graph reconstruction is not annual, it is continuous. Incremental graph update is the hard requirement, and the reference implementation does not do it.

Decision rule. Approve when multi-hop exceeds roughly a quarter of queries, the corpus is stable, and the relationships are genuinely implicit in prose — legal discovery, incident forensics, research synthesis. Reject when entities are already structured, when the corpus churns daily, or when the proof of concept compared GraphRAG against a naive vector baseline with no reranker, which is the usual reason the proof of concept looked good.

Stack. Graphiti for incremental, bitemporal graph construction — the property that makes it viable under churn. Kùzu embedded, or Neo4j when the graph is a shared asset. LightRAG and nano-graphrag as substantially cheaper implementations of the same idea. Microsoft GraphRAG as the reference paper, not the production system.

Where answers fail. Debating graph databases. The question is whether you will spend $180,000 without measuring the size of the population it helps.