/
.webp)
Generated by Master Biographer | Source for LinkedIn Content
New York City. Sometime in the early 2000s.
The server racks hum at a frequency that feels less like sound and more like pressure. DoubleClick's infrastructure team has been here before — that moment where the monitoring dashboard stops being informational and starts being accusatory. Latency creeping. Query queues backing up. The Oracle database, that cathedral of enterprise computing, groaning beneath a load it was never architected to carry.
They are serving 400,000 ad requests per second.
Let that number sit for a moment. Not 400,000 per day, like an ambitious marketing campaign. Not 400,000 per hour, which would itself be extraordinary. Per second. Every second of every minute of every hour, the internet — all those browsers, all those eyeballs, all those milliseconds of human attention — is demanding that DoubleClick decide what ad to show them. Right now. Before the page finishes loading. Before the user gets bored and moves on.
And the relational database, that elegant invention of E.F. Codd and IBM's research labs in the 1970s, is not built for this. It was built for payroll systems. For inventory management. For situations where data sits in neat rows, where you know what questions you're going to ask before you ask them, where the schema doesn't change every time someone in product has a new idea.
Dwight Merriman, the CTO who built all of this, understands the irony better than anyone. He is, in a very real sense, a victim of his own success. He built DART — Dynamic Advertising Reporting and Targeting — by hand, the initial system coded personally on a 486 PC connected via ISDN line. He built the infrastructure that could determine within 15 milliseconds which banner ad to show which user. He built the system that, by December 1998, would deliver 5.6 billion ads in a single month.
And now that system is hitting a wall that no amount of hardware can solve.
You can't index your way out of this. You can't add RAM. The problem is structural. The relational model requires joins. Joins require full scans. Full scans, at 400,000 requests per second, become catastrophic. The data model that Oracle and every enterprise database vendor in the world offers you assumes your data is flat, predictable, and patient. Online advertising is none of those things.
Merriman files this away. Not as a complaint. As a question.
What would I wish I had?
He won't answer that question for another six years. But when he does, the answer will reshape the entire database industry.
The story of MongoDB doesn't start in 2007. It starts in 1995, when Kevin O'Connor and Dwight Merriman launched DoubleClick out of an office in Atlanta — really, initially, a concept developed in O'Connor's basement — with a very simple premise: companies needed a way to run ads across the internet, and someone needed to build the plumbing.
Merriman wasn't a businessperson who learned to code. He was an engineer, in the deepest sense. He thought in systems. He thought about how data moved, how requests were handled, how scale changed the nature of every architectural assumption you'd made when the load was small. When DoubleClick needed its core technology built, he didn't hire a team first. He built it himself, on that 486 PC, over an ISDN connection that would feel comically slow today.
What he built was DART — and DART was genuinely revolutionary. Not in a press-release, tech-company way. In a real, mechanical way. It could take a user arriving at a webpage and decide, in milliseconds, which ad to show them. Not randomly. Based on who they were, where they were, what time of day it was, what content they were looking at. Real-time behavioral targeting, implemented at internet scale, years before anyone else was doing it.
The system worked. It worked almost too well. DoubleClick grew from twelve employees in 1996 to over two thousand employees across twenty-five countries by 2000. Revenue went from $6.5 million in 1996 to $505 million in 2000. They went public in February 1998 — the stock opened at 87% above its offering price on the first day. By early 1999, they were serving ads on 6,400 websites globally.
This is the context that matters: Dwight Merriman spent a decade building, scaling, and fighting with the infrastructure required to run the internet's advertising backbone. He wasn't some product manager who heard that databases were hard. He was the person who spent ten years personally experiencing what happens when your data requirements outgrow the available tools.
The data wasn't structured. Ad performance varied by publisher, by placement, by user, by time of day. Campaigns changed. New data fields appeared. Schemas evolved. Every time the product team wanted to track a new signal, it meant a migration, an ALTER TABLE, a moment of holding your breath while the database locked and the production servers waited.
And the query patterns were insane. You'd need to read a user's profile, match it against campaign criteria, check frequency caps, apply exclusions, log an impression, and return a response — all in under 15 milliseconds. Relational databases could do each of those things. They struggled to do all of them together, in parallel, at 400,000 times per second, without falling over.
Merriman noted the gap between what existed and what was needed. He kept working. He kept scaling. He kept patching. And he kept asking himself that question: What would I wish I had?
April 2007. Google acquires DoubleClick for $3.1 billion.
The deal is massive — a signal that Google, already dominant in search advertising, is serious about owning the entire display advertising ecosystem. For DoubleClick's team, it is a validation and an ending simultaneously. The company they'd spent over a decade building now belongs to a larger machine.
Merriman doesn't stay long. He's not the type. He's already thinking about the next thing.
What he's thinking about, specifically, is the cloud. It's 2007, and the internet is undergoing a structural shift. Amazon has been quietly running AWS for a year. The idea that you could rent computing infrastructure — pay for what you use, scale up when you need to, scale down when you don't — is starting to feel less like a novelty and more like the obvious future of how software gets built and deployed.
Merriman pulls in two people who understand this as deeply as he does. Kevin P. Ryan, the former CEO of DoubleClick and the person who'd helped build it into an advertising empire. And Eliot Horowitz — a younger engineer who'd done his own founder stint, building and selling ShopWiki, and who thought about database and infrastructure problems with the same obsessive precision Merriman did.
They found 10gen on February 28, 2007. The name is a reference to tenth-generation computing — a gesture toward what they believed the next era of infrastructure would look like.
Their vision is ambitious, maybe too ambitious: they want to build a complete platform-as-a-service. Not just a database. Not just a compute layer. The whole stack. An environment where developers could write applications and deploy them to the cloud without thinking about servers, without managing infrastructure, without worrying about scale. "What we were building," Merriman would later say, "was very similar to what App Engine eventually became."
The platform has a name. It's called Babble. And for a period of months in 2007, it's what 10gen is.
There is a problem, though. Two problems, actually.
The first is the database layer. They're trying to build a cloud platform entirely on open source components, and when they get to the database, nothing fits. The existing options — MySQL, PostgreSQL, the standard relational suspects — don't have the properties they need for a cloud architecture. They need something elastic. Something that can scale horizontally, that doesn't require you to know your schema before you start building, that can handle the kind of unpredictable, document-shaped data that modern web applications produce. "We felt like a lot of existing databases," Merriman says, "didn't really have the cloud computing principles you want them to have: elasticity, scalability."
So they build their own. An internal database, underneath the platform they're building. They call it MongoDB — a truncation of "humongous," a word chosen to capture the scale it's meant to handle. It's not a product. It's infrastructure. It's the engine under the hood of the car they're selling.
The second problem arrives from Mountain View. In April 2008, Google launches Google App Engine.
The room goes quiet when this happens. Not literally, but functionally. The startup building a cloud application platform just watched the largest technology company on earth ship a cloud application platform. For free.
Merriman calls the team together. The conversation is not easy. They've spent a year building Babble. People have made decisions, written code, signed up for the mission. But Merriman has been in this industry long enough to know what it looks like when the ground shifts.
"Okay," he says. "What should we do? We need to reduce scope."
What follows is the kind of strategic clarity that only comes from genuine crisis. They look at what they've built. The platform is interesting. The database is extraordinary.
Developers keep asking about the database.
Every meetup, every demo, every conversation where they show off what 10gen is doing — people want to talk about the database. Not the platform. The database. This thing they built as internal infrastructure, this unglamorous engine underneath the product, is the thing that makes people lean forward.
So they make the call. They scrap Babble. They take the database — MongoDB — and they open-source it. In February 2009, 10gen releases MongoDB to the public.
What happens next surprises even them.
2009 is a specific moment in internet history.
The web has been scaling for a decade, but something changes around this time. The applications getting built are different in kind from what came before. Facebook has 300 million users. Twitter is exploding. Foursquare launches in March of 2009 and immediately starts generating geolocation data at volumes nobody expected. Craigslist is serving millions of listings. The New York Times is trying to build digital infrastructure. The new breed of application doesn't have a fixed schema, doesn't have predictable query patterns, doesn't fit neatly into rows and columns.
The NoSQL movement — a loose coalition of engineers and companies who've been building non-relational databases to solve specific scale problems — is gathering momentum. CouchDB, Cassandra, and Redis are all part of the conversation. But MongoDB arrives at this moment with something the others don't quite have: an experience that feels immediately familiar.
The documents. JSON. The query language that feels like the data structures you're already working with. The ability to just start building without defining your schema first. You don't have to think about migrations before you have data. You don't have to think about normalization before you have a product. You just start.
Developers fall in love with it.
The early adopters aren't slow adopters cautiously running proofs of concept. They're production deployments. SourceForge migrates. Foursquare builds on MongoDB from the beginning. Craigslist uses it for real data. The New York Times deploys it for real applications. eBay starts experimenting. These aren't toy use cases — these are companies serving tens of millions of users, and they're betting on this open-source database from a startup in New York.
10gen's business model is the open-source playbook: give the database away, sell support and enterprise features. It's not a new model, but it's the right model for this moment. In late 2010, Sequoia Capital takes notice. The partnership that shows up to their offices later tells the story simply: "It was immediately obvious they were the likely winner in this new category. They had developer love." Sequoia leads a funding round. Eventually 10gen raises $81 million total from Sequoia, Union Square Ventures, NEA, In-Q-Tel, Intel Capital, and Red Hat.
By 2012, 10gen has offices in Palo Alto, London, Dublin, Barcelona, and Sydney. The Wall Street Journal names them one of its "Next Big Things." They are not a side project. They are not a niche technology. They are the default database for a generation of developers who are building the web's next layer.
In August 2013, 10gen makes the name change official. They are no longer named after a concept. They are named after the product.
They become MongoDB, Inc.
This is the part that gets left out of the origin story.
By 2014, MongoDB is everywhere. The developer community loves it. Downloads are in the millions. The brand is synonymous with the NoSQL movement. And the company is, in the words of the person brought in to fix it, "badly missing plan."
The product had outrun the business. Leadership was fragmented. The go-to-market machine that needed to accompany developer adoption hadn't been built. Revenue was growing, but not at the pace the product momentum suggested was possible. Merriman, who'd been CEO, recognizes the problem clearly enough to do something CEOs rarely do voluntarily: he steps back and finds someone better suited to the next phase.
In August 2014, Dev Ittycheria comes in as President and CEO.
Ittycheria is not a technical founder. He is a builder of businesses around technical products. He's operated at scale. He understands what enterprise sales requires, what go-to-market discipline looks like, what needs to change for a company with developer love to become a company with enterprise revenue.
When he joins, MongoDB is doing roughly $30 million in annual revenue.
In 2016, the company launches MongoDB Atlas — a fully managed cloud database service. They're essentially doing what 10gen originally envisioned with Babble, but eight years later, with the market ready and the product proven. Atlas is MongoDB in the cloud, hands-off, auto-scaling, no infrastructure management required.
The developers who already love MongoDB can now use it without spinning up their own servers. The enterprises who want MongoDB's flexibility can have it without hiring a DBA team to manage the deployment.
Atlas changes everything. Not immediately. In 2016 it's a promise. By 2019, Atlas accounts for 40% of total revenue, growing 185% year-over-year. By 2024, Atlas is 71% of total revenue.
The managed service is the business model that the database always pointed toward. It just took until the cloud was mature enough to deliver it.
October 19, 2017.
MongoDB rings the opening bell on the NASDAQ. Ticker: MDB.
IPO price: $24 per share. By the end of the first day, shares are up more than 30%. The company raises $192 million. At the end of that first trading day, MongoDB is valued at approximately $1.8 billion.
Merriman is there. The man who coded the first DoubleClick ad-serving system on a 486 PC connected via ISDN line. The man who spent a decade watching relational databases buckle under the weight of the internet. The man who sat in a meeting in 2008 and said "we need to reduce scope" and bet everything on the database nobody was asking about yet.
He has been a co-founder and board member from the beginning. He stepped back as CEO, let someone else build the business machine, stayed close enough to watch.
This is the day the mental note — if I ever build another company, the database will be different — becomes a public market instrument.
By 2024, MongoDB is generating close to $2 billion in annual revenue. 60,000 customers across the world. The stock at various peaks has put the company's market capitalization above $30 billion. Dev Ittycheria runs it for ten years before stepping down in November 2025, succeeded by CJ Desai from Cloudflare.
The company that started as a wrong turn — the platform nobody wanted — is now the default database for applications that didn't exist when MongoDB was founded.
Here is the thing about MongoDB that most of the business school analyses miss.
It was never really a pivot. Merriman built DART on a 486 PC because he needed it to work. He built the ad-serving infrastructure at DoubleClick because the job required it. He built MongoDB's internal database engine because the cloud platform he was building needed one and nothing else was adequate. The thread that runs through all of it is the same: when the tools aren't right, build better tools.
The database was never a product idea. It was a solution to a real problem, built by a person who had been living that problem for a decade, built at the moment when the rest of the industry was finally ready to understand why the problem mattered.
The NoSQL movement didn't create MongoDB. MongoDB and the movement arrived together because the same forces — web scale, unstructured data, the impossibility of predicting your schema in 2007 for an application that wouldn't exist until 2010 — were hitting everyone at once.
Eliot Horowitz, the CTO who helped design MongoDB's architecture, gave an interview once where he tried to explain why NoSQL came to be. The answer he gave wasn't technical. It was experiential. They'd seen databases fail at scale. They'd seen the cost of rigidity. They'd seen what happened when the world needed to move faster than relational models could accommodate.
"You have to choose something else," Merriman said. "We have no choice but to not be relational."
Not a manifesto. Not a thesis. A conclusion, reached under pressure, by engineers who'd spent years watching the alternative not work.
MongoDB is, at its core, the product of constraint. The constraint of serving 400,000 ads per second with tools designed for payroll systems. The constraint of building a cloud platform in 2007 without a database that could run on it. The constraint of competing with Google App Engine with twelve engineers and a limited runway.
Every one of those constraints produced a decision that led somewhere. The decisions accumulated. The product emerged. The company formed around the product. The market formed around the company.
And somewhere, in the origin of all of it, there is a 486 PC connected via ISDN line, and a man who needed something to work.
He made it work. And then, years later, he made it different.
Sources used: Grokipedia (Dwight Merriman), Encyclopedia.com (DoubleClick Inc.), The Register (MongoDB origin feature 2011), ByteScout (MongoDB history), Sequoia Capital podcast (MongoDB crucible moments), StratimCapital (MongoDB portfolio), CNBC (MongoDB IPO coverage), TechCrunch (Founder Stories: Dwight Merriman), AdExchanger (DoubleClick oral history), multiple Wikipedia entries and MongoDB official resources.
