Vector RAG vs GraphRAG vs LightRAG: which should you use?

What is the difference between vector RAG, GraphRAG and LightRAG?

All three retrieve from your documents before an LLM writes the answer. They differ in what they index. Vector RAG indexes text chunks as embeddings. GraphRAG and LightRAG also have an LLM extract entities and relationships into a knowledge graph, then retrieve through that graph.

When is vector RAG enough?

Vector RAG is enough when the answer lives in one passage or a handful of them: a rule number, a clause, a figure in a table, a procedure. Most enterprise question-answering sits here, and it is the right baseline to build and measure first.

Super Cat Technology’s on-premise RAG system for a Big 4 firm is built on this layer. It blends keyword and semantic search, about 30 to 70, because rule numbers and names are what embeddings alone miss, and it returns the source paragraph with every answer. Most of the quality came from parsing and retrieval tuning, not from a graph.

When do you need GraphRAG?

You need GraphRAG when users ask questions about the corpus as a whole. The GraphRAG paper by Edge and colleagues, revised in February 2025, states that RAG fails on global questions such as “What are the main themes in the dataset?”, because they are summarisation tasks, not retrieval tasks.

GraphRAG answers them by extracting a knowledge graph, building a community hierarchy and generating a summary for each community. Its documentation lists four query modes: global search over community summaries, local search around specific entities, DRIFT search, and basic vector search for questions that plain RAG handles well. Expect to tune its prompts to your data.

When is LightRAG the better graph option?

LightRAG fits when you want graph-based retrieval across documents but not the community-report machinery. Its paper by Guo and colleagues, revised in April 2025, describes graph structures in indexing and a dual-level retrieval system covering low-level facts and high-level concepts.

Its maintainers state that it avoids community reports, which reduces LLM calls, and that it supports incremental updates and selective document deletion. For graph storage it supports Neo4j and Memgraph, and its documentation recommends PostgreSQL as the single production backend. The default in-memory storage is for testing only.

What can go wrong with graph-based RAG?

A graph adds capability and adds failure modes. Plan for these before you commit:

• Indexing cost. Both methods run an LLM over your documents to extract entities and relationships. LightRAG’s documentation says it needs more capable models than traditional RAG for extraction and for answering from long, noisy context.
• Extraction quality. The graph is only as good as the entities the LLM pulls out. GraphRAG’s documentation says out-of-the-box results may not be the best and recommends prompt tuning.
• Locked-in embeddings. LightRAG’s documentation says the embedding model must be chosen before indexing, and changing it means re-embedding everything, with no re-embedding tool.
• Bad parsing stays bad. A graph built from a table split mid-row or an unread scan inherits the error. Layout-aware parsing and OCR come before any retrieval method.

How do you choose between them?

Choose by the questions your users actually ask. These examples show which method each kind of question points to:

Then work in this order:

1. Build a vector and keyword baseline with citations, and a labelled evaluation set.
2. Sort the questions it fails on: single-passage, cross-document, or whole-corpus.
3. Add a graph only for the cross-document or whole-corpus failures, and re-run the evaluation.
4. Keep the source citation on every answer, whichever method retrieved it.

Where the data is confidential, all of this can run on your own infrastructure. Super Cat’s private on-premise platform for family offices is retrieval over research and holdings with every answer cited. For the build-versus-buy decision, see Enterprise RAG: build vs buy.