What Are All Those Dependencies Actually For?
Every package in LangChain and LlamaIndex, categorized by purpose
HTTP & Networking
Serialization
Own Ecosystem
NLP / Tokenization
DB / Storage
Neither framework calls HTTP directly — they pull in packages that do, which pull in other packages. This is the cascading cost of supporting async + sync HTTP across dozens of provider integrations.
httpx LC + LI
Modern sync+async HTTP client. Used by most provider SDKs.
httpcore LC + LI
Low-level HTTP — httpx depends on this. You didn't choose it.
anyio LC + LI
Async compatibility layer. Both frameworks depend on it.
certifi LC + LI
SSL certificate bundle. Required for HTTPS.
aiohttp LC only
Async HTTP client (older style). LangChain keeps it for legacy integrations.
aiosignal LC only
aiohttp dependency. Cascading cost.
multidict LC only
aiohttp dependency. HTTP header handling.
urllib3 LC only
Low-level HTTP — the requests dependency.
nest-asyncio LI only
Patches Python's event loop to allow nested async calls. A workaround bundled as a core dep.
Key Insight
SynapseKit has zero HTTP deps at core level — httpx only enters when you install a provider extra (e.g. synapsekit[openai]). Both LangChain and LlamaIndex make that choice for you whether you use a local model or not.
Every framework needs to validate inputs and serialize outputs. The question is how much of that work they pull in versus use Python's standard library for.
pydantic LC + LI
Data validation. The most conflict-prone shared dep — LangChain requires v2, LlamaIndex's old constraint allowed v1.
pydantic-core LC + LI
Rust-compiled pydantic v2 core. Fast but version-locked tightly.
pyyaml LC + LI
YAML parsing. Both frameworks use it for config files.
typing-extensions LC + LI
Backports of Python typing features. Lowest conflict risk.
marshmallow LI only
Older serialization library. LlamaIndex keeps it for legacy support.
dataclasses-json LI only
Dataclass ↔ JSON. LlamaIndex-specific utility.
dirtyjson LI only
Parses malformed JSON from LLM outputs. Useful but opinionated.
orjson LC only
Fast JSON via Rust. LangChain uses it for performance-critical paths.
The pydantic pin problem
pydantic is the highest-risk shared dep. LangChain ≥2.7.4,<3.0.0 vs LlamaIndex allowing >=1.10.0. In projects that pin pydantic v1 (common in older ML codebases), LangChain will either fail to install or produce silent type errors.
These are packages the framework authors built themselves and now bundle as core dependencies. You get them whether you want them or not.
langgraph LC only
LangChain's agent/workflow framework. Bundled at core — you didn't have to opt in.
langgraph-checkpoint LC only
State persistence for LangGraph. Core dep whether you use agents or not.
langgraph-prebuilt LC only
Pre-built LangGraph agents. Bundled automatically.
langsmith LC only
LangChain's observability/tracing platform. Bundled as core dep. You may already have your own observability stack.
llama-index-instrumentation LI only
LlamaIndex's tracing/callbacks. Core dep.
llama-index-workflows LI only
LlamaIndex's workflow/agent orchestration. Bundled at core.
The bundled observability problem
Both frameworks bundle their own observability tools (LangSmith, LlamaIndex-instrumentation) as core deps. If you're already using Langfuse, Datadog, or another tracing platform, you're carrying dead weight — and potentially two conflicting instrumentation layers.
LlamaIndex bundles NLP tooling at the core level. These are heavyweight packages that take meaningful time to import.
tiktoken LI only
OpenAI's tokenizer. Bundled at LlamaIndex core — even if you're not using OpenAI models.
nltk LI only
Natural Language Toolkit. A large NLP library bundled for text splitting utilities.
regex LI only
Alternative regex engine. Dependency of tiktoken and NLTK.
tiktoken LC only
Also in LangChain — but as a lighter dependency, not pulling NLTK with it.
The tiktoken + NLTK cascade
LlamaIndex's decision to bundle NLTK means you're importing a full NLP toolkit on every session. NLTK alone adds ~80 MB to your environment and requires downloading data separately. For a text retrieval framework, this is an opinionated default.
LlamaIndex bundles a complete ORM and async database layer at the core level. This is the clearest signal that it's building toward a data platform, not just a retrieval library.
sqlalchemy LI only
Python's most complete ORM. Core dep of LlamaIndex — available whether you use a local DB or not.
aiosqlite LI only
Async SQLite. LlamaIndex's default storage backend.
greenlet LI only
SQLAlchemy async dependency. Cascading cost.
fsspec LI only
Filesystem abstraction — S3, GCS, local, HDFS. LlamaIndex uses it for data loaders.
platformdirs LI only
Platform-specific storage paths. LlamaIndex uses it for cache directories.
SQLAlchemy as a founding thesis signal
Bundling SQLAlchemy at the core level is a clear statement: LlamaIndex intends to be your data layer, not just your retrieval layer. If you're building a lightweight RAG pipeline, you're carrying a full ORM you'll never use.
www.engineersofai.com — AI Letters #11 · Full analysis: kaggle.com/misternautiyal