Verdict
Default to LightRAG for agent knowledge bases that change: its architecture merges new entities and relations into the existing graph instead of rebuilding community structures, its retrieval is dramatically cheaper in the published head-to-head (under 100 tokens and a single API call per query, versus roughly 610,000 tokens and hundreds of calls for the GraphRAG configuration in the paper's comparison - arXiv 2410.05779, published in Findings of EMNLP 2025 - aclanthology.org/2025.findings-emnlp.568), and the project is heavily adopted - HKUDS/LightRAG is among the most-starred graph RAG repositories on GitHub, with tens of thousands of stars. Choose Microsoft GraphRAG when your queries are corpus-global - 'what are the dominant themes across all incident reports' - because hierarchical community summaries answer sensemaking questions LightRAG's entity-and-relation retrieval does not natively address, and the maintained microsoft/graphrag library now supports incremental delta updates via the graphrag update command (per Microsoft Learn guidance), retiring the old 'GraphRAG can't update' objection. Two corrections to what most 2025-era blog posts will tell you: the one-click graphrag-accelerator repo was archived on May 27, 2025 (GitHub notice) - do not build on it - and Microsoft's own answer to the indexing-cost critique, LazyGraphRAG, with its claimed ~0.1%-of-full-GraphRAG indexing cost, has shipped via Microsoft Discovery rather than as a standalone open-source drop-in. And if your workload is mostly single-fact lookups, skip graphs entirely: plain vector RAG answers those at a fraction of either system's indexing bill.
The architectures differ where agent workloads bite. GraphRAG's pipeline extracts an entity graph, then runs community detection and LLM-summarizes every community hierarchically - powerful for global questions, but the summarization pass is the cost center, and community structures are exactly what change when documents arrive (the incremental update path exists now, but reconciling communities remains the expensive part of the design). LightRAG's bet (arXiv 2410.05779) is that dual-level retrieval - low-level entity/relation lookups plus high-level keyword themes - over a flat graph gets most of the multi-hop benefit without maintaining community summaries at all, which is what makes updates a merge instead of a rebuild and retrieval a single call. Honesty about the famous numbers: the '<100 tokens vs 610k tokens' figures come from the LightRAG paper's own experimental comparison (widely echoed in secondary writeups) - an author-run benchmark on specific datasets and a specific GraphRAG configuration, not an independent replication, and blog posts that quote it as a universal constant are overclaiming. Directionally it holds, because it follows from the architecture: GraphRAG's global mode map-reduces over many community summaries per query; LightRAG retrieves a bounded neighborhood. Cost anecdotes reinforce the stakes - community reports of full GraphRAG indexing runs range from a couple of dollars on demo corpora to a widely-cited '$33k cost cliff' report on a large enterprise corpus (secondary sources; treat as anecdote, not benchmark) - and LightRAG carries its own operational tax: high-quality graph extraction leans on a capable, long-context LLM at ingestion, so cheap local models degrade the graph (a criticism that recurs across third-party reviews). Both are Apache-style open source; neither sells you anything - which is exactly why no vendor page owns this comparison.
Decision Table
| Criterion | Edge | Explanation |
|---|---|---|
| Retrieval cost per query (tokens and API calls) | LightRAG (HKUDS - dual-level retrieval over an incremental entity-relation graph) Best edge | In the LightRAG paper's head-to-head (arXiv 2410.05779), retrieval uses fewer than 100 tokens and one API call, against roughly 610,000 tokens and hundreds of calls for the GraphRAG setup in that comparison - the paper's own numbers on its own benchmark, but the mechanism is structural: GraphRAG's global search map-reduces across community summaries, while LightRAG fetches a bounded entity/relation neighborhood keyed by dual-level keywords. For an agent that queries its knowledge base dozens of times per task, per-query footprint compounds into the difference between a rounding error and a line item. |
| Global sensemaking queries ('themes across the whole corpus') | Microsoft GraphRAG (entity graph + hierarchical community summaries, map-reduce global queries) Best edge | Hierarchical community summaries are GraphRAG's genuine moat: pre-computed LLM summaries at multiple community levels let it answer corpus-wide questions no neighborhood retrieval can - that is the core finding of Microsoft's original 'From Local to Global' work and the reason the design pays its indexing bill. LightRAG's high-level keyword retrieval gestures at themes but does not aggregate over the whole corpus. If your agent's job includes portfolio reviews, trend synthesis, or 'summarize everything we know about X across 10k documents,' GraphRAG is the tool. |
| Incremental updates as the corpus changes | LightRAG (HKUDS - dual-level retrieval over an incremental entity-relation graph) Best edge | LightRAG was designed around this: new documents extract into entities and relations that merge into the existing graph - no community rebuild step exists to invalidate (arXiv 2410.05779). GraphRAG has closed much of the gap: the maintained microsoft/graphrag library supports delta updates via graphrag update --root <workspace> (Microsoft Learn), so the old absolute claim is stale - but updates still interact with community structures, the expensive part of the design, and the archived accelerator never got the feature. For agent memory that ingests continuously, LightRAG's merge-native architecture remains the lower-friction choice. |
| Indexing cost on large corpora | Tie | A third option wins this row: Microsoft's own LazyGraphRAG, announced with the claim that its data indexing cost is roughly 0.1% of full GraphRAG's - comparable to vector RAG - by deferring summarization to query time. The catch is availability: it has surfaced through Microsoft Discovery rather than as a standalone open-source release you can pip-install (Microsoft Research project page), so for self-hosters it is a signpost, not an option. Between the two contenders proper, LightRAG indexes cheaper (entity extraction only, no community summarization pass), while full GraphRAG indexing on enterprise corpora is the source of the cost-cliff anecdotes - but both still pay LLM-per-chunk extraction, which dominates either bill. |
| Extraction quality dependency | Microsoft GraphRAG (entity graph + hierarchical community summaries, map-reduce global queries) Best edge | Both systems inherit their graph quality from the extraction LLM, but LightRAG wears it worse in third-party reviews: its recommended setup calls for a capable long-context model at ingestion, and community reports consistently flag degraded entity/relation quality with small local models - garbage graph in, confident garbage out at query time. GraphRAG's community summarization adds a smoothing layer: even with imperfect extraction, LLM-written community summaries recover coherent themes. Neither is safe to index with a 7B model and forget; GraphRAG degrades more gracefully. |
| Operational maturity and ecosystem | Tie | Adoption favors LightRAG - tens of thousands of GitHub stars, a Findings of EMNLP 2025 paper, active maintenance, and a server/API mode with pluggable storage backends per its repo documentation. Institutional weight favors GraphRAG - Microsoft Research provenance, the maintained microsoft/graphrag library, and enterprise mindshare. But the row is a tie because both carry sharp edges: GraphRAG's one-click accelerator is archived (May 27, 2025, GitHub) leaving self-managed deployment as the real path, and LightRAG's velocity means breaking changes between versions. Read both issue trackers before betting production on either. |
| Simple factual retrieval (the workload that needs neither) | Tie | For single-fact lookups - 'what is the refund window,' 'which API endpoint does X' - plain vector RAG beats both graph systems: no extraction pass, no graph maintenance, indexing at embedding cost, and retrieval quality that graph structure barely improves. Graph RAG earns its cost only on multi-hop and entity-relation questions. If less than a fifth of your agent's queries are genuinely multi-hop, run vector RAG (our pgvector vs Qdrant comparison covers that layer) and revisit graphs when the query mix says so. |
Choose LightRAG (HKUDS - dual-level retrieval over an incremental entity-relation graph) if...
- Agent memory and knowledge bases with continuous document ingestion, where updates must merge rather than trigger rebuilds.
- High-query-volume agents where per-query token footprint compounds - bounded neighborhood retrieval in one API call.
- Self-hosters who want a pip-installable, actively maintained OSS stack with server mode and pluggable storage.
- Teams optimizing total cost of ownership on mid-sized corpora: cheaper indexing (no community summarization pass) plus cheap retrieval.
Choose Microsoft GraphRAG (entity graph + hierarchical community summaries, map-reduce global queries) if...
- Sensemaking workloads: executive summaries, trend analysis, and thematic synthesis across entire corpora via hierarchical community summaries.
- Enterprise environments that weight Microsoft Research provenance and the maintained microsoft/graphrag library over community-project velocity.
- Corpora that are indexed rarely and queried globally - where the one-time summarization bill amortizes across months of global queries.
- Teams with noisy source documents, where community summarization smooths imperfect entity extraction better than raw graph retrieval.
Decision rules
- 01Continuously-ingesting agent memory with multi-hop questions → LightRAG: merge-native updates and sub-100-token retrieval (per its Findings of EMNLP 2025 paper) fit the read-heavy, always-changing profile.
- 02Corpus-global sensemaking ('themes across everything') as a first-class workload → Microsoft GraphRAG: community summaries are the only mechanism on this page that actually answers those queries.
- 03Do not build on the graphrag-accelerator - archived May 27, 2025 (GitHub); use the maintained microsoft/graphrag library, which also carries the graphrag update incremental path.
- 04Treat the viral cost numbers as directional, not gospel: the <100 vs 610k token figures are the LightRAG authors' own benchmark configuration; run a 100-document pilot on your corpus and measure both indexing spend and answer quality before committing.
- 05Indexing budget is the blocker and your queries are global → watch LazyGraphRAG (claimed ~0.1% of full GraphRAG indexing cost), but note it ships via Microsoft Discovery, not as a standalone OSS package you can self-host today.
- 06Mostly single-fact lookups → skip both: plain vector RAG on pgvector or a managed store answers them at a fraction of the cost, and you can add a graph layer later without discarding the embedding index.
- 07Whichever you pick, budget for a capable extraction model at ingestion - a cheap local model building the graph is the most common self-inflicted quality failure reported for both systems.
Migration Notes
- Keep raw source documents authoritative: both systems derive their graphs from chunks, so switching (either direction, or to LazyGraphRAG if it opens up) is a re-indexing job, not data loss - as long as you own the originals.
- GraphRAG → LightRAG: you lose community summaries; if any workflow depended on global-mode answers, replicate it with a periodic corpus-summary job before cutover, or you'll discover the dependency in production.
- LightRAG → GraphRAG: budget the community summarization pass on your full corpus - the cost-cliff anecdotes came from exactly this step on large document sets; pilot on a subset and extrapolate spend before committing.
- Either → vector RAG downgrade: if the pilot shows multi-hop queries are rarer than assumed, the embedding index inside both systems is the piece worth keeping - the graph layers are removable.