LightRAG vs RAGFlow
Two of the top rag and knowledge, side by side: score, setup, license, activity and what each review found.
LightRAG
Graph-plus-vector RAG server with web UI and Ollama-compatible API
RAGFlow
RAG engine with document parsing, agentic retrieval and citations
| What we compare | LightRAG | RAGFlow |
|---|---|---|
| Score parts, out of 100 | ||
| Adoption | 80, widely used | 95, widely used |
| Freshness | 100, active | 100, active |
| Maintenance | 89, healthy | 94, healthy |
| Easy to run | 50, easy | 33, some setup |
| Agent-ready | 70, partly | 30, minimal |
| Facts from GitHub and the README | ||
| Stars | 40.1k | 92k |
| License | MIT (permissive) | Apache-2.0 (permissive) |
| Last commit | Sep 2026 | Oct 2026 |
| Last release | Sep 2026 | Sep 2026 |
| Language | Not stated | Go |
| Docker | Yes | Yes |
| GPU | Not needed | Not needed |
| arm64 or Apple Silicon | Mentioned | Not stated |
LightRAG
LightRAG indexes documents into a knowledge graph plus vector store and queries both layers, as a lighter alternative to Microsoft GraphRAG. The server package ships a REST API, a web UI for inserting and visualizing the graph, and Ollama-compatible /api routes for chat frontends. Parsing runs via MinerU, Docling or a native engine; production storage goes to PostgreSQL, Neo4j, MongoDB, Milvus or OpenSearch.
Who it is for: developers wanting graph-based RAG with a ready server
Strengths
- Dual-level graph and vector retrieval with fewer LLM calls than community-report GraphRAG
- Incremental updates and document deletion with graph regeneration from the LLM cache
- Three parsing engines and four chunking strategies, including paragraph-semantic
- Separate LLM settings per role: extract, query, keywords and VLM
Weaknesses
- Default KV, vector and graph stores are in-memory with file persistence, not for production
- Server binds 0.0.0.0 with every endpoint public until auth is configured
- Ollama-compatible /api routes stay open even with auth unless WHITELIST_PATHS is set
- docx smart headings and SVG rendering need extra spaCy models and libcairo
- no GPU
- Docker + Compose
- Needs PostgreSQL (recommended for production), Neo4j (optional), MongoDB (optional), Milvus (optional), OpenSearch (optional)
- Models: LLM and embedding providers configured in .env, tested with open models such as Qwen3-30B-A3B
RAGFlow
RAGFlow parses documents (Word, slides, Excel, TXT, images, scans, web pages) with template-based chunking, then retrieves with multiple recall and fused re-ranking to produce answers with traceable citations. Recent releases add agentic multi-step retrieval with four thinking modes and Knowledge Compilation into wikis, graphs, trees and mind maps. Models are configured by name, address and API key for the LLM, embedding and reranker.
Who it is for: Teams building document Q&A with cited answers on their own servers
Strengths
- Chunk visualization lets you inspect and correct parsing before retrieval
- Citations link answers back to source chunks
- Ingests sitemaps and Google BigQuery with incremental sync
- Apache-2.0 with prebuilt Docker Compose deployment
Weaknesses
- Stack needs MySQL, MinIO, NATS, Kvrocks, ClickHouse and a document engine
- Go backend not supported on macOS; Linux x86_64 host required
- DeepDoc OCR and layout analysis run on CPU only in 1.0
- Current release is 1.0.0-rc1, a release candidate
- RAM ≥ 16 GB
- no GPU
- Docker + Compose
- Needs Elasticsearch or Infinity, MySQL, MinIO, NATS JetStream, Kvrocks, ClickHouse
- Models: configurable LLM, embedding, reranker
- port 80