The consensus on MongoDB is simple and wrong. PostgreSQL has JSONB columns, vector extensions, and thirty years of operational maturity. MongoDB is a NoSQL relic from 2009 that solved a problem — flexible schemas — that SQL databases now solve just as well. The document model was a transitional technology that will be absorbed into the relational database the way every previous database paradigm was absorbed.
This reads the wrong part of the architecture. MongoDB's value is not that it stores documents instead of rows. It's that the document model is the native data format for AI applications, and the database is becoming the memory layer for AI agents.
AI agents produce and consume JSON-structured data. An agent that books a flight generates a structured itinerary. An agent that researches a compliance question generates a structured audit trail. An agent that calls APIs across five services stores the chain of calls, responses, and decisions in a format that maps directly to a document — nested objects, variable-length arrays, optional fields that are present in some records and absent in others. Modeling this in a relational schema requires either dozens of join tables or a JSONB column that defeats the purpose of using a relational database in the first place. Modeling it in MongoDB is the document as-is. No mapping. No normalization. No impedance mismatch between the agent's output format and the persistence layer.
MongoDB Atlas Vector Search stores vector embeddings alongside operational data in the same document Source. An AI agent that needs to find semantically similar documents — a support agent searching past tickets, a legal agent searching precedent, a sales agent searching deal history — issues a single query that combines vector similarity search with metadata filtering. The vector is a field in the document, not a separate index in a separate system. The operational data and the semantic index live in one place.
The MCP (Model Context Protocol) support is the strategic move that most investors missed. MongoDB announced its MCP server in 2025, enabling AI agents to interact directly with MongoDB databases as a native function Source. When an AI agent needs to remember context across sessions, query related documents, or search embeddings, it calls MongoDB through the MCP interface. No middleware. No custom integration. The database presents itself to the agent as a tool.
The practical implication: when an AI agent has persistent state — memory between calls, context from previous interactions, a knowledge base it queries autonomously — that state lives somewhere. It doesn't live in the LLM's context window, which is expensive and stateless. It doesn't live in a vector database that only stores embeddings and can't answer "show me the full document" queries. It lives in a database that stores both the documents and the vectors, that the agent can query through a standard protocol, and that returns results in the same JSON format the agent natively consumes. That database, for the majority of deployed AI agents, is MongoDB.
MongoDB's fiscal 2026 fourth-quarter results showed revenue of $695.1 million, up 27% year-over-year, with Atlas revenue growing 29%. Atlas now represents 74% of total revenue Source. The company acquired Voyage AI, a specialist in embedding and reranking models, to strengthen the vector search capability Source. MongoDB's developer documentation now features dedicated guidance on building AI agents, covering agentic RAG patterns, tool integration, and state management Source. This is not a database company bolting AI onto a document store. It's a database company redesigning itself around the assumption that the primary consumer of its product will be an AI agent, not a human developer writing application code.
Here's the part that doesn't show up in a database benchmark: when an AI agent needs to write its state somewhere and read it back later, it doesn't emit SQL. It emits JSON. It expects JSON back. Every translation between JSON and a relational schema is a place where the agent's output gets mangled, a field gets dropped, or a nested structure gets flattened into something the agent can't parse on the way back. The agent doesn't care about normalization. It cares about round-trip fidelity — the document it wrote is the document it gets back. That is the document model's native advantage, and it becomes more valuable, not less, as agents handle longer and more complex interaction chains.
The bear case says Postgres will absorb this too. Postgres has pgvector, JSONB, and extensions for everything MongoDB does. The technical rebuttal is that Postgres's JSONB performance degrades under the kind of deeply nested, variable-schema workloads that AI agents generate, and its vector search capability is an extension rather than a first-class feature. The business rebuttal is stronger: developers who build AI applications are not Postgres developers who discover JSONB. They are JavaScript/Python developers who reach for the JSON-native database they already know. The MongoDB developer ecosystem — drivers, ODM libraries, MCP protocol support — is built for the developer who says "just store it as a document." The Postgres ecosystem is built for the developer who says "let me normalize the schema first."
MongoDB is the default. The default doesn't have to be the best at everything. It has to be the path of least resistance for the most developers building the most applications. For AI agents that produce and consume JSON-structured state, MongoDB is the database where the state already lives in the right format. The market is pricing it like a legacy vendor being squeezed by Postgres. The reality is that the AI application layer is document-native, and MongoDB owns the developer mindshare for the document-native architecture.