Before graph-based RAG can answer one question, it must read everything and build a map. Why does that stop it scaling?

This explores what graph-based RAG has to pay to build its graph before it can answer a single question, and why that up-front bill limits deployment at scale. The corpus names the costs (construction overhead, staleness, inflexibility) but gives no dollar or token figures for building a graph. What follows is the shape of the problem, not a price list.

The first cost is processing the whole corpus in advance. GraphRAG turns the corpus into an entity graph, splits it into groups with Leiden community detection, and pre-generates a summary for each group, so global questions can be answered by map-reduce over those summaries Can community detection enable RAG systems to answer global corpus questions?. That makes global questions answerable, but every document has to be read and every group summarized before the first query. HippoRAG makes the same trade. It builds a knowledge graph up front so that Personalized PageRank can follow multi-hop paths in one step, which is 10-20x cheaper and 6-13x faster than iterative retrieval Can knowledge graphs enable multi-hop reasoning in one retrieval step?. Those savings are at query time. The note doesn't report what the build costs, so the price of admission is left out of the comparison.

The second and third costs come after the build: the graph goes stale, and it locks in one view of the data. LogicRAG's argument is that a pre-built corpus-wide graph brings construction overhead, goes out of date as the corpus changes, and fixes one retrieval logic for every question. It builds a small directed graph from each query at inference time instead, which avoids all three while keeping multi-hop reasoning Can query-time graph construction replace pre-built knowledge graphs?. My reading is that staleness is what turns a one-time cost into a recurring one. In a corpus that keeps changing, the graph is something you keep paying to maintain. StructRAG adds a related point about inflexibility: different questions do better with different structures (tables, graphs, algorithms, catalogues, plain chunks), and a router that picks per query beats uniform retrieval Can routing queries to task-matched structures improve RAG reasoning?. A graph built once for everything is a bet that a graph is the right shape for every question.

So the corpus points to two ways of paying less. One is to build lazily, as LogicRAG does, and construct structure only for the question in hand. The other is to build something lighter than a full entity graph. MiA-RAG summarizes documents first to get a global map, then retrieves against it, which recovers the discourse structure that bag-of-chunks retrieval loses Can building a document map first improve retrieval over long texts?. Neither note claims a cost win over full graph construction, so both are directions, not measured fixes.

People accept the construction cost because the alternative is failing in production. Vector embeddings measure association, not relevance, and graph-based retrieval is one of the responses to that limit on compositional, multi-hop tasks How should retrieval and reasoning integrate in RAG systems?. Production RAG also fails for reasons no graph fixes, such as attribution, security and compliance requirements, and single-pass designs Why does retrieval-augmented generation fail in production?. The collection knows why building the graph is a bottleneck. It has no head-to-head that puts the build cost next to the retrieval gains it buys.