We built a prototype using LangGraph for a multi-step document processing pipeline. It works, but I'm having second thoughts.
The graph orchestrates about five steps: fetch, parse, validate, enrich, and store. Each step is a simple Python function. Now I'm looking at it and thinking: couldn't we have just built this as a series of FastAPI endpoints and used Celery to chain the tasks? The state would be in the task result or a database row.
LangGraph's state management is neat, but it feels like we added a new framework for what is essentially a linear workflow. The learning curve for the team is non-trivial.
Has anyone else been down this path? At what point does a LangGraph setup become justified over a more traditional, "dumb" queue-based system? I'm worried about vendor/pattern lock-in for something that should be simple.
I'm the FinOps lead for a 150-person tech company. We process around 500k documents daily using a mix of FastAPI/Celery and, in one case, LangGraph for a highly conditional approval workflow.
**LangGraph vs. FastAPI/Celery: Core Comparison**
1. **Complexity Justification:** LangGraph pays off with conditional, looping, or recursive workflows. For a strict linear five-step pipeline, you over-engineered. I've seen teams waste 3 weeks adapting to LangGraph's state model for workflows a simple Celery chain solves.
2. **State Management Cost:** LangGraph's persistence is convenient but opaque. At scale, checkpointing every step to its backing store (like LangSmith) can double your runtime and add $0.02-$0.05 per 1k workflow executions. Celery with a Postgres result backend costs us ~$40/month fixed.
3. **Operational Burden:** FastAPI/Celery uses battle-tested patterns every senior Python dev knows. Debugging a stalled LangGraph workflow requires tracing through LangSmith, adding a vendor dependency. Our P95 latency for Celery tasks is 1.8s; LangGraph added 700-900ms overhead just for orchestration.
4. **Exit Strategy:** Replacing a Celery worker is changing a decorator. Migrating out of LangGraph requires rewriting your entire state flow and error handling. The lock-in risk is real for a linear pipeline.
**My pick:** For your linear five-step pipeline, refactor to FastAPI/Celery now. The complexity debt isn't worth it. Only choose LangGraph if you have a clear need for cycles, human-in-the-loop branching, or complex state recovery. Tell us your peak document volume and whether any step requires reruns based on later step outcomes.
cost per transaction is the only metric
That cost breakdown is really eye-opening. I hadn't considered the per-execution overhead of the managed state layer.
Your point about exit strategy is a big one too. Is the vendor lock-in mostly about LangSmith for monitoring, or are there other parts of the LangGraph ecosystem that make it hard to swap out later?
For a strictly linear workflow, I'm starting to think the main benefit might just be developer experience at the very start, for rapid prototyping. But that comes with a long-term cost.