BlogRun AI wherever your compliance framework demands. Read blog >

BlogRetrieval accuracy is now a competitive advantage Read blog >

Database Digest Vol. 2

When AI Outruns the Stack

Legacy architecture creates architectural drag, forcing smart enterprise AI projects into endless pilot loops.

The breaking points of a fragmented stack

The reason projects fail is not the model. It is everything beneath it: A security bolt-on, unbuilt audit trails, and late data.

Why a fragmented stack breaks agents

A chatbot only reads, but an autonomous agent must decide, transact, and continuously write state changes. Stitching separate vector engines and operational databases together with custom ETL pipelines creates four simultaneous physical friction points in agent execution.

Vector engines are read-only; agents must change state.
Missing atomic boundaries create broken transactions.

Sync lag forces agents to decide on outdated truths.

“The business wants to move fast, but the systems underneath say no. Something that should take two weeks takes six months.”

Thorsten Walther
Managing Director, CXO Advisory Asia at MongoDB

The hidden anatomy of architectural drag

Two enterprises launch identical AI initiatives on the same day, with identical engineering talent, language models, and budgets. By the end of the quarter, the first enterprise ships a production-ready agent grounded securely in real-time operational truth with structured session memory. Eighteen months later, the second enterprise remains trapped in a pilot loop—plagued by hallucinations, cloud bill spikes, data drift, and a pipeline it can’t audit.

Same talent. Same models. Same budget. The only variable is the architecture they walked in with. That gap has a name now. Call it the architectural drag, the cumulative weight a fragmented stack puts on every team trying to ship AI on top of it.

New research from IDC, commissioned by MongoDB and conducted across 1,400 organizations in eight Asia-Pacific markets, indicates that 43% of teams find existing architectures to be a major obstacle. Furthermore, IDC predicts that teams failing to address technical debt will face a 50% higher AI project failure rate by 2027.

"The hardest part of running agents in production isn't the model. It's the data layer underneath it."
— CJ Desai, President and CEO at MongoDB

According to Deloitte, 89% of enterprises are still stuck in pilot loops. Only 11% are running agentic systems in production. The bottleneck is rarely the AI model itself. It is security bolted on at the backend, unplanned audit trails, and real-time data arriving half a step too late.

A graphic showing how a fragmented bolt-on stack won't scale and will inevitably break with agent use

State changes fail

The vector store can't write, but the agent has to change state dynamically.

Broken transactions

Operational and vector stores can't share a transaction, causing half-completed customer orders.

Outdated decisions

Synchronization lag forces your agent to make decisions based on yesterday's truth.

Fragmented audit trails

When regulators ask what the agent did, the audit trail covers only a fraction of the steps because no single system saw the whole sequence.

Beyond integration sprawl

Stitching together separate stores and retrofitting document workloads into relational tables imposes high structural costs.

A diagram highlighting the "split architecture" showcasing MongoDB as an operational database and Elasticsearch as a vector database and the various complexities associated with both

Every architecture review for an agentic AI project ends up with the same question: Can the stack we already have support what we’re about to build? It’s tempting to answer it by benchmarking vector databases. The deeper question is whether your architecture can answer questions about data and meaning in the same query, with the same guarantees.

That’s what an agent actually needs. It’s the part of the stack most teams settle last, after the rest of the system has already taken shape. The operational database is treated as a given. According to Harvard Business Review Analytic Services, only 15% of organizations consider their data foundation ready for agentic AI. The result is a split architecture that looks reasonable on a whiteboard and starts to fall apart in production.

The two patterns are worth comparing honestly:

Unified architecture: A single platform handles operational data and vector search together.
Split architecture: A dedicated vector store (Pinecone, Weaviate, or a search engine such as Elasticsearch) sits alongside the operational database, with an ETL pipeline keeping the two in sync.

High integration overhead

A split architecture relies on a dedicated vector store next to an operational database, stitched by ETL pipelines. While pairings like MongoDB and Elasticsearch work in a demo, the synchronization complexity and data drift cause massive failures at production scale.

Split setups handle two query languages and duplicated data.
Deleted documents leave lingering ghost vectors behind.

Separate backup, failover, and on-call teams raise TCO.

Learn more

A graphic which breaks down the CRUD operations and how they may perform correctly on MongoDB but may fail with additional bolt ons

A graphic highlighting how one unified platform has less glue code and potential points of failure.

MongoDB vs. SQL: Beyond the myths

When a workload is JSON-shaped and iterating weekly, relational assumptions fail. Let's look past the viral myths and focus on real technical merit.

Built for real-time scale

A few themes resonate with technical leaders weighing a database stack choice in 2026. Choosing a data layer that natively matches your application's data format eliminates an entire category of overhead, engineering drag, and translation bugs.

SQL queries force 8 complex format changes per trip.
MongoDB bypasses overhead by using native JSON formats.

Relational engines paper over gaps with split layers.

Deconstructing the Postgres migration viral cycle

Every few months, a familiar blog post goes viral across the developer ecosystem: “Why we moved back to Postgres.” Almost instantly, the comment threads fill up with the exact same predictable talking points: MongoDB doesn’t scale, there are no joins, and transactions are weak. Tim Carter Clausen, who writes as The Decipherist and has run MongoDB in production for a decade, addresses each criticism directly, with real-world production data behind him.

Choosing a database with a data model that matches the rest of the stack ensures your engineering velocity remains unhampered by architectural drag.

Deep dive: The cost of the SQL translation tax

A typical SQL request makes eight format changes on a single round trip:

The client sends JSON.
The API parses it into a JavaScript object.
An ORM tool decomposes that object into rows scattered across normalized tables.
The database does its work.
The rows are reassembled.
They’re mapped back into an object.
The object is serialized back to JSON.
The response is sent.

MongoDB’s equivalent is four transformations, and Clausen argues that calling it four overstates it because the shape of the data never actually changes. Each format change in the SQL path consumes CPU and memory, introduces latency, and offers a place a bug can hide.

The reality of schema updates

Renaming a field, adding a nested object, or restructuring a document all happen live in MongoDB with zero downtime. The same operation against a large relational table can lock writes for minutes or even hours. For teams shipping weekly, the difference isn’t theoretical. It’s the difference between adding a field this afternoon and scheduling a maintenance window next quarter.

Postgres or MongoDB?

Can Postgres with JSONB and pgvector carry your enterprise into the AI era? Let's move past tribalism and look at the core technical merit.

Critical technical observations

MongoDB data expert Franck Pachot notes that a few under-the-hood realities shift this database comparison from partisan preference to core physical architecture.

MongoDB writes 10MB documents whole as one leaf block.
Postgres splits documents into 8KB chunks using TOAST.

Postgres JSON forces an internal nested-loop join.

A slide showing how MongoDB clusters data physically compared to PostgreSQL which splits it into multiple tables and indexes

The latent tax at the indexing layer

The same architectural divergence shows up at the indexing layer. Consider a query familiar to anyone running an operational system: Return the last 10 orders for a given product in a given country.

In the document model: A single compound index serves this directly, including the fields nested inside arrays.
In a relational system (JSONB): The equivalent typically requires a GIN index for the array contents, a separate B-tree index for the scalar fields, and a heavy sort the query planner can’t avoid. The plan reads more rows than necessary, scaling unfavorably as data grows. None of this is visible from the application layer, but all of it is visible on your cloud bill.

The structural power of data locality

The structural insight beneath both points is data locality. In the document model, the logical model and the physical model are identical. The shape the application writes is the exact shape the database stores, and the shape the database stores is the exact shape the retrieval layer returns to an AI agent. This equivalence completely eliminates the synchronization pipelines, double-write logic, and complex reconciliation jobs that fragmented architectures otherwise need to approximate the same outcome.

An architect's decision framework

Pachot’s decision framework lands in the direction of these technical realities:

Choose relational (Postgres): For a centralized database serving many disparate applications where the ultimate use cases aren’t all known yet.
Choose document (MongoDB): For a single application built from a domain model and persisted exactly as the application reasons about it.

The question worth asking next is which one describes the work you are building in 2026: Microservices with bounded contexts, schemas that iterate weekly, or domain objects persisted the way your application naturally thinks about them?

“A database is good and fast if you use it correctly, and the most important thing is to choose one you know, or that you want to learn.”
— Franck Pachot, AWS Data Hero & Oracle Certified Master

Watch the talk

Scaling compliance

Facing the Drug Supply Chain Security Act, McKesson must trace 1.2 billion serial numbers a year in real time. It replaced rigid SAP and Postgres tables with MongoDB, whose document model mirrors hierarchical supply chain data, and scaled operations 300-fold without flat-table join latency.