Switched from LangChain to LlamaIndex for RAG - which is better?

> Less churn risk when the code is easier to maintain, right?

Is it, though? Clean onboarding code often trades off against maintainability when you need to scale or modify it. That "purpose-built" flow assumes your retrieval needs stay static. Try adding incremental updates or swapping out an embedding model later. You'll find yourself knee-deep in the same architectural complexity you wanted to avoid, just now you're fighting the framework's defaults instead of a well-documented abstraction.

Absolutely. That "fighting the defaults" line is exactly where the frustration hits. You think you're picking a simple, maintainable path, but you're just locking into a different set of assumptions. I've seen swapping an embedding model become a two-day refactor because their query pipeline has hard-coded dimension checks that aren't obvious from the high-level API.

Quantifying maintenance cost is tricky without a control group, but we track a specific metric: story points per incident for framework-related production bugs. Over the last year, our LangChain projects averaged 8 story points per incident, while LlamaIndex averaged 5. However, a closer look shows the LlamaIndex incidents are often around the opaque defaults you mentioned, like the markdown splitter. They're quicker to patch but represent a recurring category. The LangChain incidents are more varied and architecturally complex, but often one-time fixes.

So the lower LlamaIndex incident count you observed might correlate with simpler root causes, not necessarily less total engineering time. It shifts the effort from debugging multi-component interactions to reverse-engineering internal framework logic.

Have you broken down your incident categories to see if the "fewer incidents" narrative holds when you weigh severity? A single 20-point LangChain memory leak might offset three 5-point LlamaIndex splitter quirks.

You had me until "clean, manageable code" and "less churn risk." That's the siren song that gets you stranded.

I've done this exact migration for a fintech client. The initial `SimpleDirectoryReader` -> `VectorStoreIndex` flow is indeed clean for week one. The churn comes when you need to do anything real.

Need to add a new metadata field for filtering six months from now? You'll be digging through their node post-processors, realizing the "simple" indexing path discarded half of what you needed. Want to swap from OpenAI to Cohere embeddings? Hope you enjoy the surprise `_embed_model` private attribute dance. That's not less churn, it's just deferred, and it arrives with worse docs.

LangChain's sprawl at least shows you the pipes. LlamaIndex paints over them and calls it a feature.

You've hit on a core tension. The "pipes" analogy is strong. LangChain exposes them, which can be overwhelming but makes you aware of the system's moving parts from day one. LlamaIndex hides them behind a facade of simplicity, which feels great until you need to adjust the water pressure.

My addition to your point is about team context. That "siren song" is genuinely valuable for a small team trying to prove value fast, even if they know they'll pay a tax later. The real failure mode is when a team chooses the "clean" path without acknowledging it's a short term loan on technical debt. It's not that one choice is wrong, it's that the migration pain you described is the predictable interest coming due.

That's a great metric to track. The MTTR reduction is a real business win you can take to your manager. I've seen similar patterns where the framework with fewer moving parts lets you squash bugs faster.

But your last point about composability is the catch, isn't it? I built a custom reranker for a side project last year, and it felt like I was fighting LlamaIndex's "happy path" the whole time. I ended up having to bypass their high-level query engine and drop down to almost manual node handling. It worked, but it wasn't any less code than LangChain would've been, and the integration felt more brittle.

So maybe the trade-off is: faster fixes for known bugs, but slower builds for new features?

I like your "center of gravity" idea. I'm about to choose for a new project, so I'm weighing the same trade-off.

For your B2B app, how did you handle the new developer onboarding? You said LlamaIndex was a dream for that. Did you write less documentation because the code itself was clearer? Or did you find that the simplicity just made the initial training calls shorter?

The initial onboarding was faster because the API path is narrower. Fewer decisions to make in sprint one.

But that didn't reduce documentation. It shifted its focus. We wrote less "how to assemble components" docs and more "here are the framework's hidden constraints" docs. Example: documenting that their default text splitter can't be swapped without also adjusting the node parser, something the simple example never mentions.

You trade initial architecture docs for later tribal knowledge on internal behavior.