LangChain vs LlamaIndex vs DSPy in 2026: which RAG framework earns the engineering investment

Composite of vendor documentation overviews for the three frameworks compared in this article. Sources: docs.langchain.com, developers.llamaindex.ai, dspy.ai (used for editorial coverage of the products mentioned).

The bottom line

Three frameworks dominate the production retrieval-augmented-generation (RAG) conversation in 2026, and the honest answer is that they do different jobs. RAG is the pattern of letting a large language model answer questions against a private document set by retrieving relevant snippets at query time and feeding them into the prompt. Building it production-grade requires three distinct capabilities, and each framework leads in one.

If you are building agents that take multi-step actions, call tools, and need durable execution with observability, LangChain is the strongest pick. The framework now leads with agents built on top of LangGraph, with the LangSmith tracing stack as the production-readiness anchor. ¹ If retrieval quality is the make-or-break problem, the document parsing is messy, and indexing strategy is the load-bearing decision, LlamaIndex earns the engineering investment. The framework was purpose-built around data connectors, indexes, and engines. ² If you have already built RAG infrastructure and the bottleneck is prompt-engineering toil, DSPy is the categorically different answer. DSPy compiles modular code into prompts and weights, replacing the wrangling of strings with optimisable programs. ³

For most production systems the realistic stack uses two of the three: LlamaIndex for retrieval, LangGraph for orchestration, with DSPy added later if accuracy targets demand it. Pick by the role you need filled, not by which has the most GitHub stars.

(Versions and pricing in this comparison are as of 9 May 2026; all three frameworks ship rapidly and prices fluctuate, so verify on each project’s release page and pricing page before you commit.)

What each framework actually is

The three were built to solve different problems, and the headline pitches reflect that.

LangChain: agents and the orchestration surface

LangChain positions itself as “an open source framework with a prebuilt agent architecture and integrations for any model or tool—so you can build agents that adapt as fast as the ecosystem evolves,” per the official docs. ¹ The headline abstraction is now agents, not the chains and Runnables that defined earlier versions. The 1.x repositioning shifted billing toward agents built on top of LangGraph, with chain-style code retained but no longer the front door.

The pitch the docs emphasise sits on three legs: a standardised interface across model providers so swapping vendors is cheap; a “build a simple agent in under 10 lines of code” ergonomic claim; and the LangGraph foundation that gives agents durable execution, persistence, and human-in-the-loop control. ¹ If you are building anything that walks through several tools, retries gracefully when a step fails, and needs to surface a trace of what happened to a developer the next morning, this is the framework whose abstractions are pointed at the problem.

The thing to know up front is that LangChain in 2026 is a multi-package install. The 1.x line splits across langchain, langchain-core, langchain-classic, and langgraph, each with its own version number. The latest tagged release on the main repo is langchain 1.2.18 (8 May 2026), with langchain-core at 1.3.3 (5 May 2026) on the active line and a langchain 1.3.0a2 alpha already in the pipeline; langchain-core 0.3.86 (7 May 2026) is a CVE-2026-34070 security backport to the legacy 0.3.x line, not the current core release. ⁴ Pinning LangChain in production means pinning several packages.

Image: langchain-ai/langchain, the canonical GitHub repository. The framework overview the docs at docs.langchain.com describes is the prebuilt-agent-architecture pitch quoted above.

LlamaIndex: data connectors and retrieval primitives

LlamaIndex calls itself “the leading framework for building LLM-powered agents over your data,” and the abstraction order in the docs gives the priority away. Data connectors come first, then indexes, then engines (query and chat), then agents, then workflows. ² The order matches the company’s heritage: LlamaIndex was the retrieval-first option before agents were table stakes, and the retrieval primitives are still where the framework’s depth lives.

The framing the docs lead with: large language models are trained on public data but lack access to your private, specific information, and LlamaIndex addresses that fundamental gap by ingesting, parsing, indexing and processing your data so you can implement complex query workflows on it. ² If your RAG project’s bottleneck is “we have 50,000 PDFs that the OCR keeps mangling and the chunking is destroying tables,” LlamaIndex is the framework whose abstraction surface treats that as the problem worth solving rather than as plumbing.

LlamaIndex is on a single-package model with rapid releases. The repository has shipped roughly 493 releases since the 0.x line started, with the latest at 0.14.21 (21 April 2026) and 49,300 GitHub stars. ⁵ Breaking-change discipline lives in the CHANGELOG; production teams should pin a specific version and read release notes before upgrading.

Image: run-llama/llama_index, the canonical GitHub repository. The data-connectors / indexes / engines / agents / workflows abstraction stack lives at developers.llamaindex.ai.

DSPy: a compiler for prompts

DSPy is positioned categorically differently. The Stanford NLP group describes it as “a declarative framework for building modular AI software” that “allows you to iterate fast on structured code, rather than brittle strings, and offers algorithms that compile AI programs into effective prompts and weights for your language models.” ³ The mental model is a compiler, not a runtime: you describe what the program should do (modules with typed input/output signatures), and DSPy’s optimisers synthesise the prompts and few-shot examples that make it work.

The three load-bearing primitives are modules (“describe AI behavior as code, not strings”), signatures (typed input-output specifications), and optimisers (which tune prompts and weights via few-shot synthesis, instruction proposals, and weight finetuning). ³ The pitch: instead of wrangling prompt strings or training jobs, you compose natural-language modules and let the optimiser do the prompt engineering for you, which makes the resulting AI software more reliable, maintainable, and portable across models.

Two practical things to know. First, DSPy is rarely a replacement for LangChain or LlamaIndex; it is more often a layer on top, where the underlying retrieval and orchestration sit on one of the others and DSPy handles the prompt-quality dimension. Second, DSPy is fully open source under the Stanford NLP group with no paid tier, no hosted service, and no managed plan. ⁶ Compute cost is your LLM API spend plus the compute to run the optimisers; engineering time is the real adoption cost.

Image: stanfordnlp/dspy, the canonical GitHub repository. The modules / signatures / optimisers compiler pattern is documented at dspy.ai.

At a glance: the decision-axis matrix

Axis	LangChain	LlamaIndex	DSPy
Primary use case	Agent orchestration; multi-tool workflows; durable execution	Data-heavy retrieval; document parsing and indexing-first RAG	Prompt and weight optimisation as a compiler step over your modules
Core abstraction	Agents (built on LangGraph); Runnables and LCEL retained as legacy surface	Data connectors → Indexes → Engines → Agents → Workflows	Modules + Signatures + Optimisers
API ergonomics	Verbose; multi-package import surface (langchain, langchain-core, langgraph); the docs pitch a working agent in under 10 lines	Mid-verbose; cleaner retrieval primitives; single-package install	Concise but conceptually heavy — must internalise the compile model before output makes sense
Production-readiness anchor	LangSmith tracing and observability; LangGraph durable execution, persistence, human-in-the-loop	Native observability via Workflows; LlamaCloud for managed parsing	Weakest in vendor-managed terms; production patterns are user-built; no hosted service
GitHub stars (2026-05-09)	136,000	49,300	34,300
Latest release (2026-05-09)	langchain 1.2.18 (8 May 2026); langchain-core 1.3.3 (5 May 2026); 0.3.86 is a legacy-line CVE backport	0.14.21 (21 April 2026)	3.2.1 (5 May 2026)
Licence	MIT (open source)	MIT (open source)	MIT / Apache (open source)
Paid tier (vendor-hosted)	LangSmith: Developer $0 + PAYG, Plus $39/seat/mo, Enterprise custom	LlamaCloud: Free, Starter $50/mo, Pro $500/mo, Enterprise custom	None. Fully open source
Cost meter that hurts at scale	LangSmith trace volume — 10k base traces/mo on Plus, then PAYG	LlamaCloud parse credits — 1,000 credits = $1.25, basic page parsing 1 credit	Your own LLM API spend plus optimiser compute
Best-fit decision criterion	Pick if you're shipping agents with multi-step tool use and need observability, persistence, durable execution	Pick if document parsing or indexing quality is the bottleneck and retrieval is the make-or-break	Pick if you have measurable accuracy targets and want to replace prompt engineering with optimisation

LangChain

Primary use case

Agent orchestration; multi-tool workflows; durable execution

Core abstraction

Agents (built on LangGraph); Runnables and LCEL retained as legacy surface

API ergonomics

Verbose; multi-package import surface (langchain, langchain-core, langgraph); the docs pitch a working agent in under 10 lines

Production-readiness anchor

LangSmith tracing and observability; LangGraph durable execution, persistence, human-in-the-loop

GitHub stars (2026-05-09)

136,000

Latest release (2026-05-09)

langchain 1.2.18 (8 May 2026); langchain-core 1.3.3 (5 May 2026); 0.3.86 is a legacy-line CVE backport

Licence

MIT (open source)

Paid tier (vendor-hosted)

LangSmith: Developer $0 + PAYG, Plus $39/seat/mo, Enterprise custom

Cost meter that hurts at scale

LangSmith trace volume — 10k base traces/mo on Plus, then PAYG

Best-fit decision criterion

Pick if you're shipping agents with multi-step tool use and need observability, persistence, durable execution

LlamaIndex

Primary use case

Data-heavy retrieval; document parsing and indexing-first RAG

Core abstraction

Data connectors → Indexes → Engines → Agents → Workflows

API ergonomics

Mid-verbose; cleaner retrieval primitives; single-package install

Production-readiness anchor

Native observability via Workflows; LlamaCloud for managed parsing

GitHub stars (2026-05-09)

49,300

Latest release (2026-05-09)

0.14.21 (21 April 2026)

Licence

MIT (open source)

Paid tier (vendor-hosted)

LlamaCloud: Free, Starter $50/mo, Pro $500/mo, Enterprise custom

Cost meter that hurts at scale

LlamaCloud parse credits — 1,000 credits = $1.25, basic page parsing 1 credit

Best-fit decision criterion

Pick if document parsing or indexing quality is the bottleneck and retrieval is the make-or-break

DSPy

Primary use case

Prompt and weight optimisation as a compiler step over your modules

Core abstraction

Modules + Signatures + Optimisers

API ergonomics

Concise but conceptually heavy — must internalise the compile model before output makes sense

Production-readiness anchor

Weakest in vendor-managed terms; production patterns are user-built; no hosted service

GitHub stars (2026-05-09)

34,300

Latest release (2026-05-09)

3.2.1 (5 May 2026)

Licence

MIT / Apache (open source)

Paid tier (vendor-hosted)

None. Fully open source

Cost meter that hurts at scale

Your own LLM API spend plus optimiser compute

Best-fit decision criterion

Pick if you have measurable accuracy targets and want to replace prompt engineering with optimisation

When LangChain is the right pick

LangChain is the right framework when the project is fundamentally an agent rather than a question-answering pipeline. The signal is that you have a goal-directed system that needs to call several tools in sequence, decide what to do next based on intermediate results, and recover gracefully when a step fails. Customer-support agents that read tickets, query a knowledge base, escalate to a human if confidence is low, and write the resolution to a CRM are textbook LangChain territory. So are research agents that gather sources, synthesise findings, and write structured outputs.

The LangGraph foundation is what makes the production case work. Durable execution means a long-running agent can survive a process restart without losing state. Human-in-the-loop primitives let a developer pause an agent at a sensitive step (about to send an email, about to write to a database) and require manual approval before continuing. Persistence keeps the conversation history and intermediate scratchpad in a backing store rather than in memory. These are the boring infrastructure capabilities that turn an agent from a demo into a production service, and LangChain has them in the box. ¹

LangSmith is the second leg. It is the tracing and observability layer that records every model call, every tool invocation, every intermediate prompt, and lets you replay them when something goes wrong. The Plus tier sits at $39 per seat per month with 10,000 base traces included and pay-as-you-go beyond that, plus per-deployment-run charges and per-minute uptime fees on production deployments. ⁷ The trace meter is the load-bearing cost driver: a moderately-trafficked agent at 100,000 traces a month blows past the 10,000 base allowance immediately, and the per-trace overage compounds. Treat LangSmith pricing as a variable cost, not a flat one, and model it against expected traffic before adopting.

The honest weakness is the multi-package surface. Pinning LangChain to a stable version means pinning langchain, langchain-core, langgraph, and any optional integrations separately, with each on its own release cadence. The 7 May 2026 langchain-core 0.3.86 release shipped a path-traversal CVE fix (CVE-2026-34070), which is a reminder that security backports can land on the dependency layer at any time. ⁴ Production teams need a clear upgrade rhythm and a CI gate that re-runs the agent’s regression suite on each package bump.

When LlamaIndex is the right pick

LlamaIndex is the right framework when retrieval quality is the project’s hardest problem. The signal is that the document corpus is messy: PDFs with multi-column layouts, tables that need to survive OCR, scanned forms, presentation decks, mixed languages, structured-but-not-database content. The framework was built around the question of how to turn that mess into an indexable, queryable surface, and the abstraction order (data connectors, indexes, engines, then agents) tells you where the depth is. ²

The retrieval-primitives strength shows up in concrete places. Multiple index types (vector store, list, tree, keyword table, knowledge graph) let you pick the structure that fits your retrieval pattern rather than forcing everything through a single vector store. Query engines, chat engines, and sub-question engines compose to handle multi-turn or multi-hop questions. Workflows let you orchestrate the retrieval logic without leaving the framework, which means the trace from “query in” to “answer out” stays in one mental model.

LlamaCloud is the managed-parsing layer that turns LlamaIndex’s open-source core into a commercial offering. The free tier comes with 10,000 credits, the Starter tier at $50 per month carries 40,000 credits with PAYG up to 400,000, and the Pro tier at $500 per month gives 400,000 credits with PAYG up to 4 million. Credit conversion is 1,000 credits for $1.25, with basic parsing at 1 credit per page and layout-aware agentic parsing higher. ⁸ The economics matter when you have a large corpus to ingest in bulk. A team that uses the open-source framework but does parsing in-house pays nothing; LlamaCloud is the document-parsing-as-a-service play, and it is the right buy when in-house OCR engineering is more expensive than the credit spend.

The honest tradeoff is that agent abstractions, while present, are not where LlamaIndex’s depth lives. If your project is a multi-tool, durable, observable agent first and a retrieval system second, you will end up reaching for LangGraph or rolling your own orchestration layer on top. The cleaner architecture in 2026 is often LlamaIndex as the retrieval layer composed into LangGraph as the orchestration layer, which is the stack pattern multiple third-party comparisons describe as the working production default. ⁹

When DSPy is the right pick

DSPy is the right framework when prompt engineering has become the bottleneck on quality. The signal is that you have a working RAG or agent pipeline, you have a measurable evaluation set with clear correctness criteria, and the gap between current accuracy and the target is being closed (slowly, expensively) by hand-tuning prompts. DSPy attacks that bottleneck by treating prompt construction as an optimisation problem instead of a manual craft.

The mental model takes a session to absorb. You declare modules with typed input-output signatures (a question and context as inputs, a structured answer as output, for instance). You compose them into a program that resembles ordinary Python. You then hand the program to an optimiser, which generates few-shot examples, proposes alternative instructions, and (in some configurations) finetunes underlying model weights to maximise your evaluation metric. ³ The output is a compiled artefact, a set of prompts and possibly tuned weights, that runs against your chosen model.

The fit profile is narrower than the other two. DSPy makes the most sense when you have a downstream evaluation set that gives a clean accuracy signal, when the workload is high enough that incremental quality gains have economic value, and when the team has the engineering depth to integrate the optimiser loop into a CI or release process. Teams that have already standardised on LangChain or LlamaIndex for orchestration and retrieval, and that have hit a quality ceiling on prompt-engineered pipelines, are the textbook DSPy adopters.

The honest tradeoff is that DSPy is the smallest of the three (34,300 GitHub stars, 108 releases on the 3.x line) ¹⁰ and the most research-shaped. The community is heavier on academic users and serious builders than on hobbyist tutorial-followers, which means the support surface is thinner when something goes wrong. The economic model also means engineering time is the real cost, not subscription fees: there is no managed service to outsource the compiled-pipeline maintenance to. A team adopting DSPy is committing to operate the optimiser loop, and to keep operating it, on its own.

Honest tradeoffs each framework asks you to swallow

Each framework has a weakness that the other two are stronger on. Naming them matters because pretending otherwise turns a comparison into marketing.

LangChain’s tradeoff is sprawl. The multi-package install, the legacy LCEL/Runnable surface alongside the newer agents path, the LangSmith pricing meter that scales with trace volume, and the rapid release cadence that requires CI discipline on every dependency bump all add up to a heavier operational tax than the smaller frameworks. The “agent in 10 lines of code” demo is real, but the production deployment is rarely that compact, and teams should plan for the dependency-management overhead from day one.

LlamaIndex’s tradeoff is the agent surface. The framework added agents and workflows after its retrieval-first heritage, and the depth shows in the older primitives. If your project is genuinely agent-first rather than retrieval-first, you will likely end up composing LlamaIndex’s retrieval into LangGraph’s orchestration. Third-party qualitative writeups from sources like Iternal.ai’s RAG-frameworks comparison frame this as “LlamaIndex is purpose-built for data-heavy applications with sophisticated indexing needs.” ⁹ That is consistent with the docs and with how production teams describe their stacks.

DSPy’s tradeoff is the conceptual cost. The compile-prompts-from-modules mental model is genuinely different from how most teams think about LLM systems, and the integration cost is real engineering time. Teams without a measurable evaluation set, without an accuracy target whose closure is economically valuable, or without bench strength to operate the optimiser loop will find DSPy harder to justify than reaching for the framework with more documentation and a hosted observability layer.

A directional benchmark from MorphLLM’s March 2026 framework-overhead measurements puts LangChain at 10.0ms latency overhead and 2.40K tokens per call, LlamaIndex at 6.0ms and 1.60K tokens per call, and DSPy at 3.53ms and 2.03K tokens per call. ¹¹ MorphLLM’s own caveat: framework overhead is small in absolute terms (4 to 14 milliseconds) against typical LLM API calls of 500 to 3,000 milliseconds, though token-usage differences compound financially at scale. The methodology is not externally cited, so treat the numbers as directional signal rather than as a definitive ranking.

What could not be independently verified

Three things did not surface from primary sources during research and deserve up-front hedging.

The LangChain v1.0 release blog post at blog.langchain.com/langchain-v1-0/ returned a 404 on direct fetch on 9 May 2026, with the alternative URL on the main marketing site also returning 404. The v1.x line is real and confirmed via the GitHub releases page (where 1.2.18 is the current tagged release on the main repository, with a 1.3.0a2 alpha already in the pipeline), but the canonical migration narrative for the 0.x → 1.0 transition was not retrievable from a primary URL on the day of writing. ⁴ If the post is back online by the time you read this, treat it as the authoritative reference; until then, the GitHub release notes are the canonical record.

The Iternal.ai RAG-frameworks comparison page is itself a marketing surface for Blockify, the company’s own RAG-optimisation product. The qualitative framings the page offers (“LangChain is more general-purpose with the largest ecosystem”, “LlamaIndex is purpose-built for data-heavy applications”, “DSPy: compile prompts, don’t write them”) are useful directional signal and are quoted in this article on that basis. ⁹ The quantitative claims on the same page (78x RAG accuracy improvement, 3.09x token efficiency gain, 40x dataset size reduction) are Blockify’s own product results, not independent framework benchmarks, and are not surfaced here.

Pricing tiers shift quarterly across this category. LangSmith’s $39 Plus tier and LlamaCloud’s $50 Starter tier are the 9 May 2026 numbers. Tier names, prices, included quotas, and overage rates have all moved within 90-day windows in adjacent tooling categories, so re-fetch each pricing page before committing budget. The same caveat applies to GitHub release tags, which we expect to drift inside the article’s editorial lifetime.

How to choose: a three-question decision tree

Three questions, in order, decide the right pick for most production teams.

First, is the project fundamentally an agent? An agent is a system that takes goal-directed actions, calls multiple tools in sequence, and needs to recover from intermediate failures. If yes, LangChain (with LangGraph for orchestration and LangSmith for observability) is the strongest fit. The cost driver to model is LangSmith trace volume.

Second, is retrieval quality the project’s hardest problem? Document parsing on messy corpora, indexing strategy, multi-hop question handling, and chunking-quality work all signal yes. If yes, LlamaIndex is the strongest fit, with LlamaCloud as the managed-parsing buy when in-house OCR engineering would cost more than the credit spend. The cost driver to model is parse credits per document at expected ingest volume.

Third, has prompt engineering itself become the bottleneck on quality? You have an evaluation set, you have a measurable accuracy target, you have engineering depth, and the gap is closing slowly via hand-tuning. If yes, DSPy is the right addition, often as a layer on top of an existing LangChain or LlamaIndex pipeline rather than as a replacement.

If you answered yes to two or three of these, the realistic stack is composed: LlamaIndex for retrieval, LangGraph for orchestration, optionally DSPy for prompt optimisation. That is the working pattern multiple production teams describe, and the third-party comparison consensus reflects the same shape. ⁹ The frameworks are not enemies; they are different layers of the same stack.

Where to go next

For each framework, the official documentation and the live GitHub release page are the canonical references that stay current as the project evolves.

LangChain documentation and the main GitHub repository cover the agent surface, the LangGraph integration, and the multi-package release rhythm. LangChain pricing covers the LangSmith tiers in detail, including the per-deployment-run and per-uptime-minute charges that the topline tier headers do not show.

LlamaIndex documentation and the main GitHub repository cover the data-connector and index abstraction surface. LlamaIndex pricing covers the LlamaCloud tiers and the credit-conversion rate for parse-volume planning.

DSPy and the Stanford NLP GitHub repository cover the modules-signatures-optimisers surface and the active 3.x release line.

Re-read this comparison if any of three things change in the next six months: LangChain’s pricing meter restructures (likely), LlamaIndex pivots its agent surface (possible), or a credible peer-reviewed benchmark publishes framework-comparable accuracy data (unlikely but the most editorially load-bearing event of the three).