LightRAG is a Python retrieval-augmented generation framework, released under the MIT licence and presented in an EMNLP 2025 paper, that builds a knowledge graph over documents so that queries can be answered from both graph structure and vector similarity.

What it is

LightRAG sits in the Python LLM tooling ecosystem, alongside projects such as GraphRAG, and it targets the RAG layer that most applications otherwise assemble by hand. It indexes documents into a knowledge graph, stores that graph and its embeddings across configurable backends, then serves retrieval at query time. Storage is not fixed: the project supports PostgreSQL, MongoDB, Neo4J and OpenSearch as backends, with MongoDB and PostgreSQL usable as all-in-one storage solutions and OpenSearch integrated as a unified backend covering all four LightRAG storage types.

The concrete problem it solves is the cost and fragility of graph-based RAG pipelines. Graph-indexed retrieval traditionally means slow indexing and a hard choice between graph traversal and vector search; LightRAG combines the two and exposes the result through a single API, a WebUI, and a Docker-based setup wizard. Recent work removed processing bottlenecks to support large-scale datasets efficiently, and document deletion now triggers automatic knowledge graph regeneration so that removing a source does not silently degrade query quality. It replaces the custom glue code that teams write to stitch together an extractor, a graph store, a vector store, and a query rewriter.

Key capabilities

• Knowledge graph extraction with accuracy improvements targeted at open-sourced LLMs such as Qwen3-30B-A3B.
• Role-specific LLM configuration across four distinct roles: EXTRACT, QUERY, KEYWORDS, and VLM, each with independent model settings.
• Four selectable text chunking strategies: Fix, Recursive, Vector, and Paragraph.
• Multimodal parsing through the merged RagAnything work, using MinerU or Docling services for text, images, tables, and equations.
• OpenSearch as a unified storage backend, plus Neo4J graph support and MongoDB or PostgreSQL as all-in-one storage solutions.
• RAGAS for evaluation and Langfuse for tracing, with the API returning retrieved contexts alongside query results to support context precision metrics.
• Reranker support, enabled as the default query mode, and citation functionality for source attribution and document traceability.

Who uses it and how

• Teams running private document search who need a web-facing entry point can use the LightRAG WebUI to insert, query, and visualize knowledge through a dashboard.
• Applications that already run PostgreSQL or MongoDB can point LightRAG at the existing database instead of operating a separate store, since both are supported as all-in-one storage.
• Installations with existing Neo4J graph infrastructure can reuse it for storage rather than adopting a new graph database.
• Deployments that require local model execution can run embedding, reranking, and storage backends locally via Docker, keeping the retrieval stack on their own hardware.
• Projects evaluating retrieval quality can wire in RAGAS and Langfuse to measure and trace query performance over time.
• Multilingual and multimodal pipelines can route PDFs, images, Office documents, tables, and formulas through MinerU or Docling before indexing.

Getting started

The README describes an interactive setup wizard plus Docker support for local deployment of the embedding, reranking, and storage backends; running it deploys the retrieval stack and its dependencies together.

How it compares

No list of commercial products that LightRAG replaces is supplied, and the only comparable retrieval systems named in the facts are the same research group's sibling projects: RAG-Anything for all-in-one multimodal RAG, MiniRAG for simplification with small models, and VideoRAG for extremely long-context video understanding. GraphRAG appears in the project's topic list as the closest named reference point, so LightRAG's differentiation rests on its storage-backend flexibility and its Python package rather than on a documented feature-by-feature comparison.

When to use it — and when not to

A self-hoster must operate real infrastructure: a storage backend such as PostgreSQL, MongoDB, Neo4J, or OpenSearch, plus locally deployed embedding and reranking services if Docker is used, and credentials for up to four separate LLM roles. Anyone wanting a drop-in hosted service with no operational surface should look elsewhere, and the project carries 222 open issues, which is a meaningful support signal for teams without capacity to debug their own deployment. The MIT licence is clear and permissive, so the trade-off is operational effort, not legal risk.