There is a particular kind of GitHub starring spree that happens when a category gets hot, and "knowledge-graph RAG" had one. Three repos sit near the top of it — Microsoft's GraphRAG, HKUDS's LightRAG, and Zep's Graphiti — and a lot of teams pick between them by reading the README's first paragraph and counting stars. That's the wrong instinct here, because the three are not three takes on the same idea. They are three answers to a question most evaluations never ask out loud: does your knowledge sit still?
The three repos
All three will, if you squint, do the same surface thing: take your text, pull out entities and relationships, store them as a graph, and use that graph to answer questions an LLM couldn't answer well from flat chunk retrieval. The squint is the problem.
GraphRAG: built to answer the question no chunk contains
Microsoft GraphRAG exists for a specific failure of ordinary vector RAG. Ask "what does the refund policy say" and similarity search nails it — the answer lives in a chunk or two. Ask "what are the recurring themes across all our incident reports" and vector RAG falls apart, because no single chunk contains the answer; it's spread across hundreds. The accompanying paper frames this honestly as query-focused summarization, not retrieval.
GraphRAG's machinery follows from that goal. At index time it extracts an entity graph from the whole corpus, runs Leiden community detection to cluster the graph hierarchically, and then has an LLM write a summary for every community. A global query is answered by map-reduce: generate a partial answer from each relevant community summary, then reduce them into one.
The reason GraphRAG is expensive is the same reason it works: at index time, an LLM reads everything and writes a summary of every cluster it finds.
That pre-computation is the cost wall everyone complains about, and it's not a bug you can configure away — it's the design. Microsoft's own follow-up, LazyGraphRAG, attacks exactly this by deferring the LLM work to query time, which tells you how real the objection was. If your actual queries are local lookups, GraphRAG is a heavy answer to a question you don't have.
LightRAG: the same job, optimized for the bill and for freshness
LightRAG (paper, now an EMNLP 2025 entry) takes the document-RAG use case and tries to keep the graph's upside while shedding GraphRAG's two biggest liabilities: the cost of exhaustive community summarization and the pain of reindexing when documents change.
It does two things differently. First, dual-level retrieval: a low-level pass over specific entities and a high-level pass over broader themes, combined — so it reaches for corpus-wide context without pre-summarizing every community. Second, an incremental update path: new documents fold into the existing graph instead of triggering a full rebuild. For a knowledge base that grows weekly, that second property is often the whole reason to choose it.
The honest caveat: LightRAG's headline "faster and cheaper than GraphRAG" comparison is the authors' own benchmark in their own paper. It's a credible positioning claim and the architecture supports it, but it is not an independent result. Treat it as "designed to be cheaper," verify on your corpus, and don't quote the speedup as gospel.
Graphiti: the one that isn't about documents at all
Here is the distinction worth tattooing on the evaluation doc. GraphRAG and LightRAG both assume a static corpus: a pile of documents you index, then query. Graphiti assumes the opposite. It's built for agent memory — the stream of facts an agent accumulates as it runs, where yesterday's truth is today's stale belief.
That changes the data model. Graphiti is bi-temporal: it records both when a fact was true in the world and when the system learned it, so you can ask point-in-time questions like "what did we believe about this account on the 3rd." It updates continuously and in real time rather than in a batch index pass, because an agent's memory can't pause for a nightly reindex. GraphRAG has no native concept of a fact changing or expiring; Graphiti's entire personality is that facts do.
So if you're building a long-running agent that needs to remember a user, a project, or an evolving situation, Graphiti is the only one of the three actually designed for it. Pointing GraphRAG at that problem means re-batch-indexing your agent's memory on every update — which is the thing Graphiti exists to avoid.
The decision, in one axis
compare: Tool | GraphRAG | LightRAG | Graphiti ;; Built for | Global sensemaking over a static corpus | Cost-efficient document RAG with freshness | Temporal agent memory ;; Index model | Batch; Leiden communities + per-community LLM summaries | Lighter graph; dual-level retrieval; incremental updates | Real-time, continuous, bi-temporal updates ;; Handles changing facts | No — re-index to refresh | Incrementally adds documents | Yes — tracks when facts were true and learned ;; Main cost | LLM reads whole corpus at index time | Lower than GraphRAG (authors' own benchmark) | Per-update LLM extraction as memory grows ;; Choose when | "What are the themes across everything?" | Growing knowledge base, tight budget | Long-running agent that must remember and update
Count stars last. The three top repos in this category are within a rounding error of each other, and the number tells you nothing about which fits your problem. The question that does is the one above: a fixed pile of documents you want to interrogate for themes points at GraphRAG, the same job on a budget with documents that keep arriving points at LightRAG, and an agent whose knowledge changes under it as it works points at Graphiti. If you're still deciding whether you need a graph at all, that's a different and prior question — start with GraphRAG vs vector RAG before you pick the tool.
