LangChain "Goes Off-Script" and Builds a Database from Scratch?

LangChain — arguably the company that understands Agents best in the world — suddenly wrote a distributed database from scratch. Is it riding the wave, or was it forced into a corner?

The Most Mainstream Agent Framework Company Is… Building a Database?

First, some background: LangChain is one of the world’s most popular AI Agent development frameworks, with tens of thousands of developers using it to build all kinds of agent applications. On May 13, 2026, LangChain published an official blog post with a deceptively calm title: We built SmithDB, the data layer for agent observability [1].

A company that builds Agent frameworks went and, on the side, wrote a distributed database from scratch. It sounds like: a noodle shop suddenly starting to sell flour (very likely the choice you make after reality smacks you in the head a few times).

A bit more background here: within the LangChain ecosystem there’s an important tool called LangSmith, used specifically to observe every inference, every tool call, and every conversation of an Agent. LangSmith originally used ClickHouse — a top-tier analytical database in the industry.

The problem they ran into is that AI Agents are evolving so fast that a single task or trace can nest hundreds of spans. LangSmith users pour in so much data every day that, under ClickHouse’s architecture, it just doesn’t hold up — both the data volume and the payloads blew past the limits.

“only supports multi-replica clusters (read scaling), not multi-shard clusters (write scaling).” ClickHouse supports read scaling, but its write-scaling support is poor. You can throw machines at reads, but for writes you just have to grind through.

LangChain’s choice for solving this problem was to flip the table — and “originate” a distributed database of its own, SmithDB.

Highlight 1: Treating Agent Traces as a New Data Type

SmithDB’s first highlight is that it doesn’t store traces as ordinary logs — instead, it treats Agent traces as a new data type.

Traditional logging systems are better at handling individual records that have already finished, but Agent traces aren’t like that: a single run may split into multiple events, a span may stay open for a long time, and the inputs and outputs may mix in large chunks of JSON, text, multimodal content, and tool-call results.

Highlight 2: A Very Lightweight Architecture

The second highlight is how lightweight the architecture is: it stores persistent data in object storage, records segment metadata in a small Postgres metastore, and keeps the query, write, and compaction services as stateless as possible. So when scaling out, instead of maintaining a pile of complex database nodes with local disks, you just add compute resources.

Highlight 3: Reading Hot Data Locally

For the third highlight, SmithDB records which write node produced each segment, and if that node is still online, queries can read the latest data directly from it (an idea very reminiscent of the LSM Tree in traditional databases).

Highlight 4: A Run Is “a Stream of Events,” Not “a Row of Records”

The final highlight is that it treats a run as “a stream of events,” not “a row of records.” SmithDB designs event fanout, merge, and compaction strategies specifically for this model.

SmithDB’s performance numbers are impressive too: P50 latency of 92 ms to load a trace tree, 71 ms to load a single run, and 400 ms for full-text search. Compared to the original LangSmith experience, that’s 12x faster.

But Zlatan thinks: the real story isn’t the numbers on the performance gains — it’s that SmithDB was purpose-built for Agent traces.

The Truly Interesting Part May Not Be the Technology Itself

LangChain building SmithDB signals an industry judgment more important than the technology: the data that Agent runtimes produce is extremely valuable, but general-purpose databases may not handle it well.

Agent data is a completely different beast from traditional database data. It’s semi-structured, with free text and vectors mixed into a single chunk of JSON. It’s high-frequency write, where a single conversation can spit out dozens of records. It’s long-lived, where a span can stay open across several hours.

A Green Data Loop Makes Life Better

An Agent’s most precious asset is the “personalized experience” it accumulates while running for you. If this raw data can be captured, distilled, and fed back in, the Agent starts to “build a memory.”

LangChain clearly gets this. The “text search,” “JSON filtering,” and “tree-aware queries” in the SmithDB community blog post translate to: we don’t just store traces, we want traces that can be fed back in and put to use.

Run the Agent once, and it gets a little smarter. The tighter the loop, the faster the evolution.

The AI Agent “Data Hunger” Problem

As AI Agents run into the “data hunger” problem more and more often, LangChain’s approach is quite interesting.

Zlatan thinks: Agent companies like LangChain building their own databases are still at a very primitive “discover that some scenario doesn’t work, then patch it” stage. AI Agents are evolving extremely fast, and within a few more days they’ll very likely run into new problems like data sharding, disaster recovery and backup, and security compliance.

Some Reflections

With this move, LangChain punched through a thin paper wall: the messy stuff Agents produce — reasoning chains, tool calls, context, feedback — is more than many databases can handle.

This isn’t a headache for LangChain alone. Where does Claude Code store its conversation history? JSONL files. OpenClaw? Markdown. The more meticulous teams reach for SQLite. Want vectors? Install pgvector. Need to store context? Add Redis. Data gets shuttled back and forth between them, losing precision and burning tokens with every move.

LangChain went from the Agent framework downward and built a database layer underneath. So what about the reverse? Going from a more mature database layer upward, to attach an Agent framework on top? So that from the very first line of code an Agent runs, the data it produces naturally lives in a very mature database.

This forms an interesting contrast with LangChain’s approach. The database pitfalls LangChain is now stepping into, database companies stepped through and out of many years ago.

Agent run produces data → stored into OB4AI
        ↓
Context / Memory system distills automatically
        ↓
Evaluation filters out high-quality data
        ↓
High-quality data feeds back into the Agent
        ↓
Agent performs better → the loop accelerates

Approach	Characteristics
Traditional approach	Every step of the loop happens in a different system; the cost of shuttling data is extremely high
A “maybe” better approach?	All data lives on the same foundation from the start, so the whole loop is an “inner loop”

What’s more?

With its in-house SmithDB, LangChain proved one thing: the Agent industry is shifting from “racing on whose model is smarter” to “racing on whose data foundation is more solid.”

On May 30, the OceanBase × LangChain Meetup will feature a major new product launch!

Reference: We built SmithDB: https://www.langchain.com/blog/introducing-smithdb