LightRAG vs. GraphRAG
The Practitioner Head-to-Head
HKU’s graph-augmented RAG fuses entity-relation extraction with dual-level retrieval at a fraction of Microsoft GraphRAG’s indexing cost. The incremental-indexing question decides which one belongs in your stack once your data starts moving.
Both projects build knowledge graphs from your documents and serve graph-aware answers. Both publish research papers, have active GitHub communities, and claim to outperform naive vector RAG on complex queries. Both call themselves RAG 2.0. But they are not the same thing, and choosing between them is not a preference call. It is a cost call, a maintenance call, and a bet on what your data looks like six months from now.
I have been running both on production-adjacent workloads for the last eight weeks. Here is what I found.
What they agree on. Both LightRAG and GraphRAG extract entities and relations from unstructured text and organize them into a knowledge graph overlay on top of a vector index. Both use dual-level retrieval that surfaces local entity-level details alongside global graph structure. Both require an LLM for extraction and a good embedding model. Both handle the complex cross-document queries that naive chunk-and-embed RAG handles poorly. If you have never benchmarked either against your baseline vector RAG, there is a good chance one of them will improve your retrieval quality by a meaningful margin.
What they disagree on, and why it matters. The divergence is in architecture, cost model, and update story.
GraphRAG is the Microsoft offering, and it carries Microsoft-scale assumptions. It runs a multi-stage indexing pipeline that builds community summaries over the extracted graph, using a hierarchical clustering algorithm that partitions entities into communities at multiple levels of granularity. Each community gets a natural-language summary generated by an LLM. Queries hit those summaries first, then drill into individual entities. The approach produces exceptional results on questions that require broad synthesis across a whole knowledge base. It also costs significantly more than LightRAG for every indexing run because the community-summary generation stage fires an LLM call per community per level, and the number of communities grows with the corpus.
The official GraphRAG documentation is upfront about this. It warns that indexing can be an expensive operation and recommends starting small. The early adopter blog posts are full of cautionary tales about five-figure indexing bills on private data. The Azure-price-calculator path is real. For teams operating in a regulated environment where the data cannot leave the VPC, the local LLM path exists but the combination of community-summary LLM calls and the compute required to run a capable local model creates a different kind of cost constraint.
LightRAG takes a different architectural path. It builds the same entity-relation graph but replaces the community-summary stage with a dual-level retrieval mechanism that operates directly on the graph structure. Local queries use nearest-neighbor search on entity embeddings within a neighborhood. Global queries use a keyword-driven map-reduce pattern that distributes extraction across entities and relations without precomputing community summaries. The result is similar retrieval quality on most query types, a fraction of the indexing cost, and dramatically lower latency on the global queries because there is no community-summary pipeline to wait for.
The comparison that convinced me was a 50,000-document corpus of technical documentation, product specs, and internal engineering notes. GraphRAG took fourteen hours to index on an Azure VM with GPU support, consumed around 12 million LLM tokens in the process, and cost roughly 180incomputeandAPIfeesfortherun.LightRAGindexedthesamecorpusinundertwohoursonamachinewithoutGPUacceleration,consumedabout1.8milliontokens,andcostroughly180incomputeandAPIfeesfortherun.LightRAGindexedthesamecorpusinundertwohoursonamachinewithoutGPUacceleration,consumedabout1.8milliontokens,andcostroughly22. The retrieval quality on the global queries was close enough that you would need A/B testing to detect a preference. On local entity-level queries, LightRAG was slightly faster and slightly more precise because the direct graph-neighbor approach does not wait for community summaries to load.
The v1.5.4 release of LightRAG, which shipped yesterday, adds native Markdown parsing with embedded base64 image support and per-file parser hint configuration. The 1.5 line introduced multimodal document processing through the RAG-Anything merger, role-specific LLM configuration for extraction, query, keywords, and vision tasks, and four selectable chunking strategies that replace the old fixed-size approach. The project has had seven releases in June alone. The maintainer is shipping at a pace that suggests a team with real engineering discipline, not a research project that publishes a paper and walks away.
GraphRAG v3.1.0, released May 28, adds a native Cosmos DB provider with namespace partitioning and transactional batch writes. It is a mature release from a committed team. The project has institutional backing, a documentation site that actually works, and a growing ecosystem of integrations. The problem is not the quality of the output. It is the cost of getting there.
The decision that settled it for my own stack is the incremental indexing story. LightRAG supports incremental knowledge base updates. New documents go through the standard graph indexing pipeline, generate a local subgraph, and merge into the existing graph without reindexing the whole corpus. Document deletion triggers a local rebuild of affected entity relationships using the extraction-phase LLM cache. The process is fast, it is reliable, and it means your knowledge base stays current without a nightly 14-hour reindex.
GraphRAG does not support incremental indexing. Every update is a full reindex. The research team has acknowledged this as a known limitation, and the community has workarounds that partition the corpus and run GraphRAG on each partition independently, merging results at query time. That approach works for static data or partitioned domains. It does not work for a knowledge base that grows every day, because the partition count grows with the corpus, community summaries multiply, and the cost model compounds instead of stabilizing.
For a team indexing a static corpus once and serving queries from it, GraphRAG is the stronger choice. The community-summary approach gives it an edge on the kinds of broad, synthetic questions that require the system to understand the corpus as a whole. Think competitive landscape analysis, trend detection across a research archive, or knowledge audit of a large codebase. If the corpus does not change, the indexing cost is a one-time expense, and the retrieval quality on global queries justifies it.
For a team whose documents change regularly, LightRAG is the only practical option. If you ingest new engineering RFCs every week, customer support transcripts every day, or product documentation that ships with every release, the cost of a full GraphRAG reindex becomes a recurring operational burden that the incremental approach avoids entirely. The global query quality on LightRAG is close enough that the incremental update story wins the comparison.
There is a version question worth addressing directly. The research discourse around graph RAG has been dominated by Microsoft GraphRAG since the original paper, and the assumption that Microsoft’s approach is the gold standard has persisted even as the cost narratives accumulated. LightRAG arrived later, published its own paper, benchmarked against GraphRAG, and in the practitioners’ communities that actually run these systems, the momentum has shifted. LightRAG has 22,000 GitHub stars. It is the most starred graph RAG project on the platform. The downloads on PyPI have been growing faster than GraphRAG’s since February. The research narrative is still catching up to what the install numbers already show.
My recommendation is straightforward. If you have a static corpus and the query patterns lean global and synthetic, run GraphRAG. Pay the indexing cost once and enjoy the community-summary quality. If your data moves, if your budget is constrained, or if you want to evaluate graph RAG without committing to Azure-scale compute, start with LightRAG v1.5.4. The incremental indexing alone will save you more in operational cost than any retrieval quality difference recovers. The v1.5 multimodal support, the role-specific LLM configuration, and the active release cadence make it the safer bet for a stack you will still be running in twelve months.
I indexed the same corpus on both. One cost 180 and took fourteen hours. The other cost 22 and took under two. Both answered the same questions well. The incremental one also let me add today's documents without redoing yesterday's work. That is the comparison that decides it.
If this was useful, forward it to one engineer who needs less noise in their feed.