Search "best RAG framework" and you'll get the same three names every time: LangChain, LlamaIndex, Haystack. All three are excellent, and all three are the same kind of thing — libraries you import and assemble into your own application. That's one layer of the open-source RAG world, and it's the one that gets written about.
The other layer is the finished engine: a system you deploy, point at your documents, and use — ingestion, retrieval, and often a whole UI already wired together. This is where teams that don't want to spend three weeks gluing a chunker, a vector database, a reranker and a generation loop into a working app actually start. The real first decision in RAG isn't which library — it's library or engine at all.
If you land on "engine," three open-source projects dominate the conversation. The temptation is to read them as competitors choosing between the same job. They aren't. Each one bets on optimizing a different part of the problem.
RAGFlow: the document-understanding bet
RAGFlow's whole identity is "quality in, quality out," and it earns it before retrieval ever happens. Its DeepDoc pipeline is a vision-and-parsing layer that recognizes document layout — tables, figures, headings, columns — and applies template-based, explainable chunking you can actually visualize and correct. That directly attacks the quiet killer of production RAG: a table flattened into garbage text poisons the embedding of its whole chunk, and no reranker downstream can recover what the parser destroyed. If your corpus is messy real-world documents — financial filings, scanned contracts, slide decks — this is the engine that takes that seriously. At roughly 83k stars and shipping releases through mid-2026, it's also the most-adopted of the set.
R2R: the production backend bet
R2R ("RAG to Riches") makes the opposite bet from Kotaemon: no opinion about your interface, a strong opinion about your backend. It's a containerized REST API with multimodal ingestion, hybrid search with reciprocal-rank fusion, automatic knowledge-graph construction, agentic multi-step retrieval, and — the part that separates a backend from a demo — user auth, access control, orchestration, and observability. People call it "the Supabase for RAG," and that's the right mental model: the plumbing you'd otherwise rebuild, exposed as a service to build your product on. One honest flag: at ~8k stars it's the smallest here, and while the main branch still saw commits late in 2025, there hasn't been a tagged release since mid-2025. It's maintained, but the momentum has cooled — weigh that before you build a company on it.
The three aren't competing on the same axis. RAGFlow optimizes what goes into the index, R2R optimizes the retrieval service, Kotaemon optimizes the experience. "Best" only means anything once you've named which of those is your bottleneck.
Kotaemon: the turnkey-interface bet
Kotaemon is the one you stand up in an afternoon. It's a clean, customizable chat-with-your-documents web UI built on Gradio, aimed at two audiences at once: end users who just want to ask questions of a folder of PDFs, and developers who want to customize the retrieval and generation pipeline underneath. It supports multiple LLM providers (OpenAI, Azure, Cohere) and local models via Ollama and llama.cpp, with multimodal QA over figures and tables. At ~25k stars and a release as recent as May 2026, it's the healthiest "give me a working app now" option.
The fourth lane, and a maintenance warning
There's a fourth obvious engine that optimizes a fifth thing entirely:
Onyx (formerly Danswer) isn't a document-QA engine so much as a connector-driven enterprise search platform — the open-source answer to Glean. If your problem is "search across Slack, Drive and Confluence," it's the right tool and the other three aren't.
Two cautions the star counts won't tell you. Weaviate's Verba was archived in June 2026 — read-only, don't start there. And Quivr, despite a huge star count, quietly repositioned from a "second brain" app into an opinionated library — which is fine, but it means it now lives on the build-it-yourself side of the line, not the deploy-an-engine side. The lesson generalizes: in a space this fast, check the last release date before you check the star count. The two best-maintained engines here — RAGFlow and Kotaemon — aren't the ones with the most GitHub history. They're the ones still shipping. And once you've chosen one, the work that actually moves quality is the same as ever: evaluate the pipeline, because no engine retrieves well by default.
