# Fast GraphRAG Tools Compared: Four Families, Not One Race

Someone sent me a shortlist. fast-graphrag, LightRAG, Graphiti, Graphify, Axon, Understand-Anything, FalkorDB — *which one should we use for our knowledge base?*

It is a completely reasonable question and it has no answer, because those seven things are not seven options. They are three different problems and a database. Asking which is best is like asking whether you should use Postgres, Grafana or a CDN: the honest response is another question.

So this is the taxonomy I gave them, the decision tree that follows from it, and what the published benchmarks actually say once you read past the headline.

## The taxonomy that makes the shortlist tractable

**Sort by what the tool ingests, not by what it produces.** All of these produce a graph. That is the least interesting thing about them.

| Family | Ingests | Answers | Tools |
| --- | --- | --- | --- |
| **Corpus GraphRAG** | Documents, prose | "What does the corpus say about X, across sources?" | Microsoft GraphRAG, LightRAG, fast-graphrag |
| **Temporal agent memory** | Conversation episodes, events | "What did we establish, and what has since changed?" | Graphiti |
| **Code intelligence** | Source repositories | "What breaks if I change this function?" | Graphify, CodeGraph, Axon, Understand-Anything |
| **Storage substrate** | Nodes and edges | Nothing — it stores what the others build | FalkorDB, Neo4j, Memgraph, LadybugDB |

The last row is where most tool round-ups go wrong. **FalkorDB is not a GraphRAG alternative; it is a layer underneath one.** Graphiti runs *on* FalkorDB. Putting them side by side in a comparison table is a category error, and it matters practically: choosing a database and choosing a retrieval strategy are independent decisions, and conflating them means you make one of them by accident.

```mermaid
graph TD
  Q["What are you indexing?"] --> C{"Source material"}
  C -->|"Source code"| CODE["Code intelligence Graphify · CodeGraph · Axon · Understand-Anything"]
  C -->|"Conversations, events"| MEM{"Do facts expire or get contradicted?"}
  C -->|"Documents, prose"| DOC{"How many documents?"}
  MEM -->|"Yes"| GRAPHITI["Graphiti bi-temporal, needs a graph DB"]
  MEM -->|"No"| DOC
  DOC -->|"Under ~1k"| STATIC["Build-time graph ship a static file"]
  DOC -->|"~1k to 100k"| FAST["fast-graphrag or LightRAG incremental, no rebuild"]
  DOC -->|"Over ~100k"| MSGR["Microsoft GraphRAG community summarisation earns its cost"]
  GRAPHITI --> DB[("Storage: FalkorDB · Neo4j Neptune · LadybugDB")]
  MSGR --> DB
  FAST --> DB
```

The first branch is the one that resolves most of the confusion — code and prose are genuinely different problems, and a tool built for one is not a weaker version of a tool built for the other. Storage sits underneath all of it, which is why it never belongs in the same comparison.

## Family 1: corpus GraphRAG

All three build an entity-and-relation graph over documents and use it to retrieve. They differ in what they do at index time, which is where all the cost lives.

|  | Microsoft GraphRAG | LightRAG | fast-graphrag |
| --- | --- | --- | --- |
| Index-time work | Extraction, Leiden clustering, community summarisation | Extraction only | Extraction only |
| Retrieval strategy | Hierarchical community summaries | Dual-level keyword retrieval | PageRank-based graph exploration |
| Adding a document | Incremental via `graphrag update`, but community recomputation can trigger and degrade to a full reindex | Union-merge into the existing graph | Incremental |
| Strongest at | Global "what are the themes" questions | Cheap, frequent updates | Multi-hop precision at low cost |
| Weakest at | Cost and update latency | Relational fidelity | Newer, smaller ecosystem |

The architectural insight worth carrying: **Microsoft GraphRAG's community summarisation is simultaneously its unique capability and its cost problem.** Clustering the whole corpus and summarising each community is what lets it answer "what are the major themes here" — a question ordinary top-k vector retrieval handles poorly, because the answer lives in the structure across documents rather than in any single most-similar chunk. Since v1.0 it does support incremental indexing via `graphrag update`, which diffs new content against the existing index and tries to place new entities into existing communities without re-running Leiden over everything. The honest caveat is in the word "tries": each update still pays LLM extraction on the new documents, and if enough changes accumulate the community layer recomputes and the worst case degrades to the cost of a full reindex. So it's incremental, not free-incremental. LightRAG's central move is to drop the global clustering entirely and merge new nodes and edges with a union, which makes updates reliably cheap; the trade is weaker performance on questions that need the global view.

fast-graphrag takes a third path: keep the graph, skip the clustering, and use PageRank to decide which parts of the graph to explore for a given query. Personalised PageRank from the query's entry-point entities is a genuinely good fit for multi-hop retrieval, because it naturally weights nodes by how reachable they are from what you asked about.

### What the benchmarks actually say

fast-graphrag publishes benchmark numbers, and they are striking. On a 51-query slice of 2WikiMultiHopQA:

| System | All queries | Multi-hop only |
| --- | --- | --- |
| Plain vector DB | 49% | 32% |
| LightRAG | 47% | 32% |
| GraphRAG (nano-graphrag) | 75% | 68% |
| **fast-graphrag** | **96%** | **95%** |

⚠️ **Read the baseline before you read the winner.** These are the vendor's own numbers, on query sets of 51 and 101 — small enough that a handful of items moves the percentage several points. The "GraphRAG" row is **nano-graphrag**, a community reimplementation, not Microsoft's. And a benchmark published by the tool that wins it is evidence of a plausible direction, not a settled ranking. I would run my own 30 questions before believing any of it, and so should you.

The line nobody quotes is the more useful one. On HotpotQA, the **plain vector database scored 78% and LightRAG scored 55%**. A graph system, decisively beaten by an embedding index, on the vendor's own chart. That is not an argument against graphs; it is the reminder that *graph retrieval helps on relational and multi-hop questions and can actively hurt on ordinary topical ones*. If your users mostly ask "find me something about X," a graph may be a costly way to get worse answers. This is why I keep arguing for hybrid retrieval rather than graph-only — the same point I made in [RAG from the ground up](rag-fundamentals).

## Family 2: temporal agent memory

[Graphiti](https://github.com/getzep/graphiti) is doing something the corpus tools are not, and the difference is worth understanding even if you never use it.

It maintains a **bi-temporal** graph: every fact carries both when it was true in the world and when the system learned it. When new information contradicts an existing fact, Graphiti does not overwrite — it closes the old fact's validity window and records the new one. The old belief remains queryable.

That sounds academic until you need it. "What did we think the customer's plan was in March?" is unanswerable in a system that overwrites. For an agent holding a months-long relationship with a user whose circumstances change, the ability to say *this was true, then it stopped being true on this date* is the entire product.

The cost is real: it requires a graph database, it does LLM extraction per episode, and bi-temporal modelling is genuinely harder to reason about than a flat graph. Use it when facts expire. Do not use it as a document retriever — that is not what it is for, and it will be an expensive way to do a simpler job.

This connects to something I flagged when writing about [build-time knowledge graphs](build-time-knowledge-graph): dated claims must stay dated. Graphiti is what that principle looks like when someone takes it seriously enough to build the whole system around it.

## Family 3: code intelligence

Graphify, CodeGraph, GitNexus, Axon and Understand-Anything all index source repositories, and I compared the first three in [detail earlier this year](code-knowledge-graphs-graphify-codegraph-gitnexus). The two additions are worth a note.

**Axon** indexes a codebase into a graph and exposes it over MCP plus a CLI, with community detection for clustering and a Sigma.js dashboard for exploration. **Understand-Anything** takes the plugin route — a Claude Code plugin that produces a JSON knowledge graph plus guided tours of the codebase, working across a dozen or more agent platforms.

The reason these belong in their own family: **code already has a formal structure that a parser can recover exactly.** The compiler knows what calls what. These tools use tree-sitter to recover relationships that genuinely exist, rather than inferring them from prose. That makes their output categorically more reliable than anything extracted from documents — and it means their hard problems are different ones (incremental reindexing, cross-language resolution, monorepo scale).

⚠️ **Both Axon and Graphiti list Kùzu among their graph backends — and Kùzu was archived on 10 October 2025**, with the team acqui-hired by Apple per a February 2026 EC filing. Neither project is at fault; the dependency went away underneath a whole cohort of tools at once. But if you adopt either, pick a different backend: Graphiti also supports Neo4j, FalkorDB and Neptune, and Axon supports Neo4j. This is the second time in two days I have hit this while researching, which tells you how widely that one archival propagated.

## Family 4: the storage substrate

[FalkorDB](https://www.falkordb.com/) is a graph database — sparse-matrix based, Cypher-speaking, positioned on low-latency multi-graph workloads, and used as a Graphiti backend where per-tenant isolation matters. It competes with Neo4j and Memgraph. It does not compete with anything else on the shortlist.

The decision that actually matters here is upstream of product choice: **do you need a graph database at all?** Below a few tens of thousands of nodes, the honest answer is usually no. A graph that size serialises to a few megabytes of JSON and traverses in memory faster than a round trip to any database. You need one when the graph exceeds memory, when several writers need transactional concurrency, or when per-node access control forces queries server-side. Those are real situations and none of them are "we have a thousand documents." I went through the mechanics in [index-free adjacency and Cypher](neo4j-graph-databases).

## The decision, compressed

| If you are… | Start with | Not because it's best, but because… |
| --- | --- | --- |
| Indexing a repo for an agent | Graphify / Axon / Understand-Anything | Code structure is recoverable exactly; don't infer it |
| Building agent memory where facts change | Graphiti + FalkorDB or Neo4j | Bi-temporal is hard to retrofit and nothing else does it |
| Under ~1,000 documents | Your own build-time pipeline | The whole graph fits in a browser tab; frameworks add ops |
| ~1k–100k documents, frequent updates | LightRAG or fast-graphrag | Incremental merge; no rebuild on every insert |
| Over ~100k documents, thematic questions | Microsoft GraphRAG | Community summarisation genuinely adds information |
| Asking mostly topical questions | A vector index, and stop | The benchmarks show graphs losing here |

💡 **The evaluation that settles it costs an afternoon.** Write 30 real questions your users would ask, split into topical and multi-hop. Run them through a plain vector index first — that is your baseline and it is often better than expected. Then run the graph candidate. If the graph does not clearly beat the baseline on the multi-hop half, you have your answer, and it is the cheap one. Most tool selection arguments are won or lost by whoever bothered to build the baseline.

## What I would actually watch out for

**Star counts are weather, not climate.** Several of these repositories are months old with tens of thousands of stars and hundreds of open issues. That is a signal of attention, not of stability, and the two are frequently inversely related in this corner of the ecosystem.

**Extraction cost is the line item that surprises people.** Every tool in families 1 and 2 runs an LLM over your corpus, and re-runs it when the extractor changes. Model the cost of a full re-extraction, not just the first index, because you will do it more than once.

**Nobody's benchmark is your benchmark.** Published numbers come from question sets chosen by the publisher, on corpora nothing like yours. They are useful for ruling things out and nearly useless for ruling things in.

## What to carry away

These tools are not competitors, and treating them as a single leaderboard guarantees the wrong choice. Sort by what goes in: source code, conversation episodes, or documents. That one question eliminates most of the shortlist immediately, and the storage layer drops out of the comparison entirely because it was never a peer.

Within corpus GraphRAG the real axis is what happens at index time. Microsoft GraphRAG buys global thematic reasoning with clustering you must redo; LightRAG and fast-graphrag buy cheap incremental updates by giving that up. Pick according to whether your corpus churns.

And run the vector-only baseline before any of it. The most quoted number in this space is the one where a graph system wins; the most useful one is where a plain embedding index beat a graph system by 23 points on ordinary questions.

#### 🕸️ Related deep dives

1. [Build-time knowledge graphs: when GraphRAG is the wrong tool →](build-time-knowledge-graph)
2. [GraphRAG: when your vector database doesn't know the whole story →](graphrag)
3. [Code knowledge graphs: Graphify vs CodeGraph vs GitNexus →](code-knowledge-graphs-graphify-codegraph-gitnexus)
4. [Knowledge graphs and the semantic web →](knowledge-graphs-semantic-web)
5. [Evaluating LLM and agent systems in production →](evaluating-llm-agent-systems)

## Frequently asked questions

### Is fast-graphrag better than LightRAG?

On fast-graphrag's own benchmarks it scores far higher — 96% vs 47% on a 51-query 2WikiMultiHopQA slice. Those are vendor-run numbers on small query sets, and the GraphRAG baseline is nano-graphrag rather than Microsoft's, so treat them as directional. The architectural difference is real: PageRank-based exploration versus dual-level keyword retrieval with union-merge updates.

### What is Graphiti used for?

Agent memory, not document retrieval. It keeps a bi-temporal graph tracking both when a fact was true and when the system learned it, closing a fact's validity window rather than deleting it when contradicted. That makes point-in-time queries possible. It needs a graph database — Neo4j, FalkorDB or Neptune.

### Is FalkorDB an alternative to GraphRAG?

No. It is a graph database, so it competes with Neo4j and Memgraph, not with retrieval frameworks — Graphiti runs on top of it. The category error matters because choosing a database and choosing a retrieval strategy are independent decisions.

### Do I need a graph database for GraphRAG?

Only above a few tens of thousands of nodes, or with concurrent transactional writers, or when per-node access control forces server-side queries. Below that, a few megabytes of JSON traversed in memory beats any network round trip.

## References

- [circlemind-ai/fast-graphrag](https://github.com/circlemind-ai/fast-graphrag) and its [published benchmarks](https://github.com/circlemind-ai/fast-graphrag/blob/main/benchmarks/README.md)
- [HKUDS/LightRAG](https://github.com/HKUDS/LightRAG) — dual-level retrieval with incremental union merge
- [getzep/graphiti](https://github.com/getzep/graphiti) — bi-temporal graphs for agent memory
- [From Local to Global: A Graph RAG Approach](https://arxiv.org/pdf/2404.16130) — the Microsoft GraphRAG paper
- [harshkedia177/axon](https://github.com/harshkedia177/axon) and [Egonex-AI/Understand-Anything](https://github.com/Egonex-AI/Understand-Anything) — code intelligence graphs
- [FalkorDB](https://www.falkordb.com/) — the storage layer, not a peer