MongoDB ended its 2026 fiscal year at about $2.5 billion of revenue, which Pete Johnson puts at roughly 3% of a database market worth $100 billion to $110 billion.
A crowd of startups sells vector databases, which store data as lists of numbers so that software can search by meaning rather than by keyword. MongoDB bought none of them. It built the capability into its existing product in-house and spent its acquisition money on the model that generates the numbers instead.
"Most people think embedding models are commoditized and that is not true."
Johnson is field CTO of AI at MongoDB, has visited seven countries this year, and says he has talked to about 100 enterprise customers about where they are in their AI projects.
I listened to the full interview so you can skip it. 97 minutes of audio, 19 minutes of reading.
Here are the 15 takeaways that matter.
👤 Guest: Pete Johnson, field CTO of AI at MongoDB, who has spent this year visiting about 100 enterprise customers across seven countries to see what they have actually deployed
🎙️ Host: Nathan Labenz, founder and former chief executive of the generative-video company Waymark, who hosts The Cognitive Revolution
📰 Published: 1 September 2026 on cognitiverevolution.ai
🔴 YouTube | ⏱️ 1 hr 37 min | ✅ Time saved: 1 hr 18 min
Key Takeaways
Agent memory is the unsolved problem, and forgetting is the part nobody has cracked A colleague gave Johnson four words for the job: write, change, recall, forget
Embedding models are not a commodity, and Anthropic's recommendation is the evidence Johnson says the Voyage models are worth as much as 14% better retrieval than the alternatives
Cramming a million tokens into every agent loop costs money and costs accuracy He cites studies putting the value in the first and last several thousand tokens, with the middle adding noise
Scale only starts to bite at around 100,000 vectors
Bad data quality is not fixed by AI, it is amplified by it
AI projects fail because of the problem chosen, not the technology used Call centers are the popular first target because cost per call is already measured
Lines of code is the wrong measure of an AI coding tool
The two most sophisticated customers he saw this year were in Mexico City and Sao Paulo
1. As old as SQL
Johnson opened with sixty years of database history, and used his own birthday as the anchor.
The relational database was designed around the cost of disk. He dated it to June 1970, when Edgar F. Codd, an IBM researcher, published the white paper that gave rise to SQL "So I am as old as SQL, Nathan." Johnson was born in February 1970 Of the three pieces of hardware — memory, compute and storage — storage was the most expensive in 1970, so data was split across linked tables to avoid storing anything twice His example: he and his wife share an address, so a retailer holds one table of people, one of addresses, and a third linking them
MongoDB was designed around the cost of time. The first commit was October 2007, the year the iPhone launched in the United States, with forty-seven years of Moore's law in between Cloud and mobile applications could not take the weekend off, so the scarce resource stopped being disk
The speed claim is a count of disk reads. Storing each person's record with the address repeated inside it costs duplicated storage and returns the same data in one read instead of three
MongoDB stores data as JSON, the same format an application programming interface returns, and keeps it in a binary version called BSON on disk, so nothing is converted along the way
"But when you need speed, when you need scale, and increasingly, when you need better retrieval quality, that's really where MongoDB shines."
Labenz's reply: "Reminded of the old saying that the problem has faded, but the solution persists."
2. $2.5B of a $110B market
Labenz put MongoDB's market value at $30 billion and asked how enterprises actually choose.
"Like you just said, we're in, like, seventy five percent of the Fortune 500."
The revenue is small against the market it sells into. Johnson said MongoDB finished fiscal 2026 at about $2.5 billion and is now in fiscal 2027, which he put at about 3% of a $100 billion to $110 billion database market
There is no single buying pattern. Some customers pick per workload, some go all in, and which depends on how much of their software is new rather than inherited, and where their engineers' existing skills sit
He said the number of problems better suited to MongoDB than to SQL has grown because of AI, and named the reason as retrieval quality rather than speed or scale
Enterprise appetite is real enough to run at hackathon scale. He described a hackathon at a major North American automaker where about 250 engineers were trained and turned loose for three days, and new product ideas came out of it
The applications there spanned customer experience, dealer efficiency, mechanic efficiency and the in-car experience
3. Not schemaless, flexible
Labenz described himself as drawn to the schemaless model because he likes to make a mess and clean it up later. Johnson pushed back on the word.
"Most people think that we're schemaless, and that's not actually true." What MongoDB is, he said, is schema flexible
The unit is a document, not a row. Documents in the same collection do not all have to have the same shape, which is why people assume there is no schema at all
The pain it removes is the migration. Changing a SQL schema already in production cascades through multiple tables; adding an attribute to a document does not
Labenz raised the temptation the AI era creates, and Johnson took it up. Dumping everything into a database in the hope an AI will use it later means updating the same address in two places, and it ends with a million tokens going into the model on every call
4. Search built backwards
Johnson called MongoDB's route into AI retrieval an unusual one, because it started with keyword search rather than with vectors.
Lexical search came first, in 2020, because customers were building it themselves. MongoDB saw people standing up their own Apache Lucene servers next to their clusters purely to get keyword search, and built the capability in as Atlas Search
Vector search was a small addition, not a new engine. A vector is an array of floating-point numbers produced by passing text, an image, audio or video through an embedding model, so to MongoDB it was one more attribute on a document with an index on top
Hybrid search is the combination, and it was in place by 2023. Johnson's worked example is a book: keyword search on the title, vector search on the synopsis, and a filter on the year of publication applied before either
MongoDB ships in three forms — community, where the customer runs and supports it; enterprise advanced, mostly on-premises, where MongoDB supports it; and Atlas, the managed service on Amazon, Google or Microsoft data centers
The newest pieces collapse two round trips into one. New aggregation-pipeline stages called rank fusion and score fusion run the keyword search and the vector search on MongoDB's side and return one sorted result set
The features came from users asking, not from a roadmap. "But my joke for this, Nathan, is there's two kinds of developers. There's those that love MongoDB and there's ones that haven't tried us."
5. Chunk size is a tradeoff
Labenz asked how a book's worth of text should be split up before it is turned into vectors — by act, chapter, section, paragraph or sentence.
Both directions of the tradeoff cost something. Chunks cut down to a sentence lose the context that sentence sat in; chunks of several pages raise storage costs and dilute retrieval quality
"I've been doing this a long time, Nathan. The answer is always it depends." The normal method is to pick a chunk size, test the retrieval quality, and repeat three or four times
Voyage's answer is to send the text twice. Johnson said the technique, which Voyage calls contextualized chunking, takes the sentence you want and a second string carrying the surrounding context, and returns one vector balancing them Plotted against chunk size, retrieval quality with an ordinary embedding model rises, flattens and then falls; this is the attempt to escape that curve It inverts the usual relationship. Johnson said you can get better retrieval quality at a smaller chunk size, which is not otherwise possible Version three shipped last summer and version four in the last six weeks
The other dial is the size of the vector itself. An embedding space runs from about 256 numbers up to 2,048, and more of them means richer retrieval and more storage The Voyage models order those numbers so a corpus embedded at 1,024 can be tested at 512 by discarding the second half, instead of re-embedding everything. Johnson's analogy for it was a set of Russian nesting dolls
The reason for building it is a bet on who is coming next. Johnson expects more developers to build AI agents in the next three years than did in the last three, and said the learning curve has to come down for that to happen
6. Scale bites at 100K vectors
Labenz described his own system — five years of email, Slack messages, direct messages, published writing and speaker-labeled podcast transcripts, with a keyword layer and a Gemini embedding layer bolted on — and asked how he would know if it was underperforming.
"It adds up to about a gigabyte in my case." Labenz said he has not really optimized it and let the agent choose its own database
Johnson's answer was that most people start exactly there. Postgres with the pgvector extension, and whichever embedding model comes with the cloud they are already on
The scale threshold is a number. He put it at about 100,000 vectors, depending on chunk size, as the point where scale starts to matter
The quality threshold is a benchmark result. "If you look at Voyage AI model, Hugging Face has a benchmark out there called RTEB that Voyage AI models are typically at the top of, and we can get as much as 14% improvement compared to some of those other embedding models that we just mentioned." His framing of what that buys: whether a 14% difference is the difference between a hallucination and a correct answer
"Most people think embedding models are commoditized and that is not true."
"Anthropic does not have an embedding model in market. They recommend us."
7. Bitter-lesson engineering
Labenz raised what he called bitter lesson engineering — periodically going through a stack and removing the workarounds that the models have since made unnecessary — and asked whether retrieval was getting easier that way.
Johnson named two examples, both of them MongoDB removing its own plumbing. The first is a re-ranking stage, which reorders search results before they go into the model's context window Previously a developer ran the vector search, sent the results to a separate re-ranker, and waited for both; the new stage does both in one call to the server
The second is automatic embedding. The customer names a collection, an attribute, a Voyage model and a number of dimensions, and MongoDB keeps the vectors current When a document with that attribute changes, MongoDB re-embeds it and updates the index; when a new document arrives, the same The point, he said, is that nobody has to build and then maintain their own embedding pipeline
The stated goal for all of it is giving developer time back. Johnson returned to that phrase repeatedly — time to spend on business logic rather than on plumbing
8. Agent memory's history
Asked what a good memory system looks like today, Johnson answered with a chronology.
The first architecture had no memory at all. When ChatGPT arrived at the end of 2022, a query went into the context window, the model processed it, and that was the end of it
Retrieval-augmented generation solved the private-data problem. Models are trained on public data, so proprietary data has to be injected at query time rather than through expensive fine-tuning
Tools and the Model Context Protocol solved the stale-data problem. A model has a knowledge cutoff, so in spring 2023 it could not give you MongoDB's share price; by 2025 it could call a tool and go and find it
Looping agents created a third problem, and that is where memory came in. Early attempts crammed the whole session into the context window for short-term memory, and every session of the last three days for long-term
Token maxing has two costs, and the second one is quality. "There's a couple academic studies that show that, like, the first seven k and, like, the last seven k tokens are the most important, and the stuff that's in between can end up just muddying and confusing the LLM as it's trying to come up with an answer." "So instead of thinking of how could I maximize, how could I cram a 100 a million tokens into the context window every time, what if I could choose just the right 200,000 for this agentic loop?"
The cautionary tale he named was Uber. Johnson said the company burned through its token budget for 2026 in thirteen weeks earlier in the year, and that the headlines around it changed the conversation
Taxonomic memory is the newest type he sees in large companies. An industry or a company has its own vocabulary, so instead of loading all hundred terms every loop, the system retrieves the five that matter for this one
9. Write, change, recall
Labenz described his own maintenance problem: monthly log files of a couple of hundred thousand tokens, rolled into monthly summaries, then yearly summaries, under a wiki-style structure of linked entities, split across a database and a file system. His complaint was that the models kept treating abandoned projects as live.
"This is the hardest problem with agents right now, I think."
"We've been building agents for, like, eighteen months, man. Like, nobody knows all the answers yet." Against sixty years of building databases
The application now has two jobs where it used to have one. It queries the memory system, often with a token budget rather than a query per memory type, and then has to send the answer back so the system can curate and store it
Shared memory is a permissions question. The more sophisticated systems use role-based access control, so two people in the same job can reuse each other's memories
The four verbs came from a colleague, and Johnson quoted him deliberately. "The way that one coworker just wrote this to me yesterday, I wanna quote him. Write, change, recall, forget." His reason: memories have a half-life, and recent ones matter more than ones from weeks or months ago
Forgetting is the part he says is unsolved, and better retrieval is the partial answer he offers for it
10. Graphs, and where they stop
Labenz said his notes form a graph — people, the organizations they work for, the ideas he associates with them — held together by pointers he trusts the agent to follow.
A better re-ranker is the cheapest improvement available. "You can get depending upon the use case, you can get like a five to 10% boost at your retrieval quality just by using a re ranker on top of whatever your embedding model of choice is."
The hybrid pattern he sees is a shallow graph with vector search at the leaves. Two to six levels of graph structure, then a vector search inside the node you land on
MongoDB's pitch here is consolidation. Because everything is JSON, a graph structure can live in the same place as the core data, the vectors, the embedding and the re-ranking
Retailers are the worked example. Product hierarchies are segmented by category as a graph, and the vector search runs inside a single category
His only named memory customer was ElevenLabs, which he called MongoDB's biggest, running multiple small agents per customer for audio editing and transformation. He noted they have not been public about how they built it
He warned against one architecture in particular. Using repeated model calls to categorize and shrink a corpus before the real model call adds tokens and, as Labenz added, latency — which is why cheaper embedding and re-ranking models are the right tool
11. Picking the right problem
Asked for his build-versus-buy view, Johnson sorted the roughly 100 customers he has met this year into three groups.
Group one bought a license and called it a strategy. A starting point, he said, but rarely specific enough to solve an enterprise's problems
Group two is stuck between proofs of concept and production, and the reason is problem selection. "The biggest difference isn't in how they're applying the tech. It's what problems they chose to try to solve."
His three questions are the problem, the data and the metric. What are the top 10 to 15 problems in the business; which of them have good data; which of them are already being measured
"Things like bad data quality and bad security posture don't get solved by AI. They get amplified by AI."
Missing metrics is the failure people skip past. "Because if you don't already have metrics for how something is performing, you won't know if it got better." Call centers are the popular first target because cost per call and call volume are already tracked, so a change can be attributed and a rough return calculated
On coding tools, the metric everyone reached for was the wrong one. "Anybody who's been doing it any length of time knows that lines of code is a terrible metric to judge the productivity of a set of developers off of." The measure he prefers is time from idea to production deployment
Group three is optimizing, and there is no standard way to do it. "There's no LAMP stack for agents right now." He expects one eventually, having lived through the same cycle in web development
12. Employee-facing comes first
Labenz described ordering a pizza from a single-location shop in Detroit and being answered by an AI agent — a good experience, he said, though it misread him when he asked which company was powering it — and asked how far the disruption has gone.
Johnson's answer was that the large companies are mostly not doing that yet. Most of the Fortune 500 customers he talks to are deploying employee-facing use cases with a human in the loop
The return is easier to prove inside the company. Every job already has key performance indicators, whether the worker is an insurance adjuster or on a manufacturing line, so a change shows up in numbers that were already being tracked
The risk is asymmetric, and that is the real reason. A salary leaking between two employees of the same company is bad; one customer seeing another customer's data is the kind of failure a vice president loses their job over "So, like, the risk reward is higher for customer facing use cases than it is for employee facing use cases."
13. MCP servers and skills
Labenz asked how MongoDB's own developer relations work has changed, given that agents now do the reading and the choosing.
Johnson highlighted two things, and said every software company is doing versions of both. The first is MCP tooling, so an agent can talk to a customer's MongoDB instances; MongoDB has had a server for a while and is now hosting some of it as part of Atlas
The second is agent skills, which he described as curated system prompts. Playbooks that used to be documentation — data modeling, operations tuning — are now markdown files handed to whichever agent the developer is using
He said MongoDB released something like six to eight of them a couple of months ago
14. Why Voyage, not a vector DB
Labenz put the strategic question directly: MongoDB built its own vector database and then bought a model company, which is the opposite of what the funding market expected.
"But the price at even at $220,000,000, which is I'm old enough to remember when that was serious money." Labenz put it at less than 1% of MongoDB's market value and asked what to infer about defensibility
Johnson's answer was that vector search was the easy half. Because the data was already JSON, adding an array of numbers and an index on it was straightforward, and it inherited the sharding, security and replication of a product that has been in production for a decade That, he said, is what standalone vector database companies have to build from nothing
The hard half was the model, and the market had mispriced it. He said the market saw embeddings and re-rankers as a commodity while MongoDB saw Voyage standing out, and repeated that Anthropic agrees
The other argument is consolidation of the console. Automatic embedding, plus managing every API key in one place instead of four — core data, vector data, embedding models, re-rankers
15. Data never stored before
Labenz relayed an argument from a vector database founder: most of the data arriving in a vector database has never been in any database, having sat in a data lake or a pile of documents.
Johnson agreed, and named the categories. Video, audio and unstructured documents — his example was a stack of PDFs sitting in SharePoint
The reason it was never indexed is that keyword search could not reach it. Vector search maps a piece of data into a geometric space, and every query is a similarity question about which vectors sit closest to the new one
The advantage he claims is having all three controls in one place. Pre-filtering on metadata, keyword search and vector search in one platform, on top of a product that already handles resilience, security and keeping data inside a given country
Bonus Insights
The one feature Johnson raised unprompted at the end was shared embedding spaces. Voyage released four versions of its version-four text model in January — the usual small, medium and large, plus a Nano that is open weight and free to download All four share an embedding space, so vectors made with one model work with the other three The use he described: embed the corpus once with the large model, then run queries through the Nano on a laptop during development and pay nothing for those tokens There is a retrieval-quality cost to mixing models, which he said outright
His closing observation was about the speed of the cycle, not the technology. MCP was published on the Monday before Thanksgiving two years ago and every competitor had adopted it as a protocol by March Token maxing, on his account, was first mentioned in early March and finished as a conversation by April
Labenz's aside, which Johnson took up: after cars, pizza is Detroit's biggest export to the world. The pizza that started it was a traditional round one, not the Detroit-style square
Johnson works out of Cincinnati, and his year has been a traveling one — Amsterdam and London earlier in the year, then Toronto, Bengaluru, Mexico City and Sao Paulo
Johnson's bottom line is that the retrieval layer, not the model, is what now decides whether an agent works — and that the industry has been building databases for sixty years and agents for eighteen months, so the answers on memory do not exist yet.
Products, Companies & Tools Mentioned
MongoDB and MongoDB Atlas Vector Search (Johnson's employer and the managed search product he says inherits its resilience, sharding and security from a decade-old core)
Voyage AI (The embedding and re-ranking model maker MongoDB bought in 2025, and the source of the contextualized chunking and shared-embedding-space features he pitched)
rank fusion and score fusion and the re-ranking stage (The query stages that turn a keyword search plus a vector search plus a re-rank into one round trip)
Automated embedding in Atlas (Keeps a document's vector current when the document changes, so nobody maintains an embedding pipeline)
MongoDB Agent Skills (Six to eight curated system prompts covering data modeling and operations, released a couple of months ago)
Apache Lucene (Customers were running their own servers of it beside MongoDB purely for keyword search, which is why Atlas Search was built)
PostgreSQL with pgvector (Where Johnson says most teams start, and what they outgrow at around 100,000 vectors)
Anthropic (Ships no embedding model of its own and recommends Voyage, which Johnson offers as proof embeddings are not commoditized)
ElevenLabs (MongoDB's biggest customer, running multiple agents per customer on audio editing, and his one named example of memory done well)
Uber (His cautionary tale: burned its 2026 token budget in thirteen weeks and made token maxing a headline)
Model Context Protocol (The tool-calling protocol he says every competitor adopted within four months of publication)
Claude Code and Codex (The coding agents behind the early-2026 boasting about five times more code, which he says measures the wrong thing)
Gemini and OpenAI embedding models (What teams default to because of the cloud they are already on — Labenz uses the first in his own system)
Vercel and Node.js (Where Labenz first saw MongoDB demonstrated about fifteen years ago, by Vercel's future chief executive Guillermo Rauch)
ChatGPT (His marker for the first agent architecture, which had no memory and no access to anything after its training cutoff)
Greg's Pizza (The single-location Detroit shop whose phone was answered by an AI agent when Labenz ordered)
Books & Resources Mentioned
A Relational Model of Data for Large Shared Data Banks – Edgar F. Codd (The June 1970 IBM paper Johnson dates SQL to, and the reason he calls himself as old as SQL)
RTEB, the Retrieval Embedding Benchmark (The Hugging Face benchmark he cites for the claim that Voyage models lead by as much as 14%)
Anthropic's embeddings documentation (Where the recommendation he cites is actually written down)
voyage-context-4 and voyage-context-3 (The blog posts behind the contextualized chunking he offered to send over, shipped last summer and in the last six weeks)
The voyage-4 model series (January's release, including the free Nano and the shared embedding space across all four sizes)
If this was worth your time, send it to someone closer to the industry than you are.
Get the latest market chatter as it happens: