The $47 Billion Argument Against Relational Databases
In June 2023, MongoDB's stock price crossed $400 per share for the first time — a moment that would have seemed hallucinatory to anyone who'd watched the company nearly self-destruct a decade earlier, when its database was a punchline in engineering forums, dismissed as a toy that lost data and couldn't handle transactions. The joke had a kernel of truth. Early MongoDB had no support for multi-document ACID transactions. It defaulted to a write concern of "unacknowledged," meaning the database told your application it had saved your data before it actually had. In 2013, a widely circulated blog post titled "Don't Use MongoDB" became a kind of catechism among serious backend engineers, cataloging the ways the document database would betray you at the worst possible moment. And yet. By mid-2024, MongoDB was generating $1.8 billion in annual revenue, growing north of 22% year-over-year, operating the most popular modern database platform among developers, and posting its first full fiscal year of positive free cash flow. The company that once couldn't be trusted with a bank transaction now ran workloads for more than 50,000 customers across every regulated industry on earth — financial services, healthcare, government, telecom. It had become, against considerable odds and through a series of deliberate, occasionally ruthless strategic pivots, the database that ate the world's application layer.
The MongoDB story is, at its core, an argument about abstraction layers — about where value accretes in the software stack and how a company can redefine a category that Oracle, IBM, and Microsoft had owned for forty years. It is also a story about the violence of business model transitions: from open-source community darling to publicly traded enterprise vendor, from on-premise license revenue to cloud-native consumption billing, from permissive licensing to a server-side public license that enraged open-source purists and kneecapped Amazon's ability to offer a competitive managed service. Every one of these transitions nearly killed the company. Every one of them was necessary.
By the Numbers
MongoDB at a Glance
$1.82BFY2025 revenue (ending Jan 2025)
50,700+Total customers
7,500+Customers with $100K+ ARR (est.)
$47B+Peak market capitalization (2024)
2,007Year Dwight Merriman and Eliot Horowitz began development
135%Net ARR expansion rate (Atlas, FY2024)
68%Revenue from Atlas (cloud) in FY2025
~5,600Employees (2024)
The DoubleClick Diaspora
To understand MongoDB, you have to understand DoubleClick — and specifically, the pain of building high-scale internet applications on Oracle in the early 2000s. Dwight Merriman co-founded DoubleClick in 1996, building the ad-serving infrastructure that would become the backbone of internet advertising. The company served billions of ad impressions daily, and its engineering team spent an inordinate amount of time fighting their relational database. The problem wasn't performance alone — it was the mismatch between the shape of their data and the rigid tabular schema that relational databases demanded. Ad-serving required flexible, hierarchical data structures that changed constantly as new ad formats, targeting parameters, and campaign types emerged. Every schema change was a migration. Every migration was a risk. Merriman, a soft-spoken technologist who'd studied electrical engineering at Columbia before drifting into software, internalized a conviction: the relational model, elegant as it was in theory, imposed an unnatural tax on application development.
Eliot Horowitz was cut from rougher cloth — a prodigy coder who'd been programming since childhood and studied computer science at Brown. He joined DoubleClick as an intern, rose quickly, and co-founded a startup called ShopWiki with Merriman after DoubleClick's $3.1 billion sale to Hellman & Friedman in 2005 (and before Google acquired it in 2008 for $3.1 billion). At ShopWiki, Merriman and Horowitz again ran into the same wall: the object-relational impedance mismatch, the endlessly frustrating gap between how developers think about data (as nested objects, as documents, as flexible structures) and how relational databases store it (as flat rows in rigidly defined tables). "We kept building the same data access layer over and over," Horowitz would later recall. In 2007, they decided to stop working around the problem and start solving it.
The project that became MongoDB — named, with the casual irreverence of the era, as a truncation of "humongous" — began as an internal component of a cloud computing platform the two were building, called 10gen. The platform itself never gained traction. The database did. By 2009, 10gen had open-sourced MongoDB and pivoted entirely to building and commercializing the database. The initial technical bet was bold and, in retrospect, brilliantly timed: MongoDB stored data as JSON-like documents (technically BSON, a binary-encoded superset) rather than rows and columns. No schema required. Developers could store whatever shape of data their application needed, nest objects within objects, and iterate without running migrations. It was, in the language of the era, "schemaless" — a word that thrilled application developers and horrified database administrators in roughly equal measure.
The Developer Love Machine
MongoDB's initial growth was viral in a way that enterprise database companies had never experienced. Traditional database sales ran through IT procurement — long cycles, RFP processes, proof-of-concept deployments, and eventually a seven-figure contract signed by a CIO. MongoDB bypassed all of that. It was free. It was easy to install. It required no schema design, no DBA expertise, no capacity planning. A developer could download it, run mongod, and start inserting documents in under five minutes. In an industry where Oracle installations required teams of consultants and weeks of configuration, this was revolutionary.
The timing aligned perfectly with three secular tailwinds. First, the explosion of web and mobile applications — Facebook launched its platform in 2007, the iPhone shipped the same year, and within three years, every company on earth needed to build applications that handled unstructured, semi-structured, and rapidly evolving data. Second, the rise of agile development methodology, which emphasized rapid iteration and deplored the kind of upfront schema design that relational databases demanded. Third, the "NoSQL" movement — a broad, somewhat incoherent rebellion against the relational orthodoxy that had governed data management since Edgar Codd's 1970 paper — which gave MongoDB a movement to ride and a community to recruit from.
The impedance mismatch between the application and the database — that's the tax every developer pays, every day. We wanted to eliminate it.
By 2013, MongoDB was the most popular database among developers on Stack Overflow and had more than 10 million downloads. The community was massive, passionate, and — critically — already embedded inside enterprises. Developers at Fortune 500 companies were using MongoDB for prototypes, internal tools, and increasingly, production workloads. The company had discovered, years before the "bottoms-up SaaS" playbook was codified, that developer adoption was the most powerful go-to-market motion in enterprise software. Developers chose the tools. Procurement followed.
But the critics weren't wrong, not entirely. MongoDB in those early years had real technical deficiencies — the default write concern issue was just the most notorious. The database lacked joins (by design, but painful in practice), had limited support for complex queries, and offered no multi-document transactions. For workloads requiring strict consistency — financial systems, inventory management, anything where "eventually consistent" meant "occasionally wrong" — MongoDB was genuinely dangerous. The company's response to these criticisms would define its next decade.
The Enterprise Pivot and the CEO Who Made It Work
Dev Ittycheria arrived at MongoDB in September 2014, and the company's trajectory pivoted with a sharpness that still surprises. A compact, intense operator with the bearing of someone who has been through exactly enough corporate near-death experiences, Ittycheria had co-founded BladeLogic — a data center automation company that he took public in 2007 and sold to BMC Software for $800 million the following year. Before that, he'd been a partner at Greylock and an executive at several enterprise software companies. He understood, in his bones, the mechanics of enterprise software sales: how to build a sales organization, how to move upmarket, how to convert developer enthusiasm into procurement dollars.
When Ittycheria took over as CEO, MongoDB had meaningful developer adoption but a chaotic business. Revenue was growing but burning cash rapidly. The sales team was subscale. The product, despite its popularity, still lacked the enterprise features — security, auditing, encryption, operational tooling — that would make a Fortune 500 CIO comfortable putting MongoDB in production for mission-critical workloads. Ittycheria's diagnosis was precise: MongoDB had won the developer heart but hadn't won the enterprise wallet.
What followed was a systematic, multi-year campaign to close the gap. On the product side, MongoDB invested heavily in enterprise features. MongoDB 3.2 (December 2015) introduced document validation and the ability to do left outer joins via $lookup in the aggregation pipeline. MongoDB 3.4 added read-only views, fine-grained access control, and encryption at rest. MongoDB 3.6 brought change streams for real-time event processing. And then, in June 2018, MongoDB 4.0 shipped with the feature that would silence a decade of criticism: multi-document ACID transactions.
The transactions release was a watershed. It didn't just add a feature — it demolished the single most powerful argument against MongoDB for enterprise use. Every CIO who'd said "we can't use MongoDB for anything that matters" suddenly could. The timing, again, was deliberate. Ittycheria had sequenced the product roadmap to match the sales motion: first win the developer, then win the enterprise, and ship the enterprise-grade features just as the sales team reached the C-suite.
Transactions are not just a feature. They are a fundamental shift in the competitive landscape. They remove the last remaining objection that kept MongoDB out of the most demanding enterprise workloads.
On the go-to-market side, Ittycheria built a layered sales organization that preserved the bottoms-up developer motion while adding the top-down enterprise muscle.
Free MongoDB Community Edition remained the on-ramp. MongoDB Atlas, launched in 2016 as a fully managed cloud database service, gave developers a one-click path from experimentation to production — and gave MongoDB a consumption-based revenue stream with dramatically better economics than on-premise licenses. Enterprise Advanced, the self-managed commercial product, served the large organizations that wanted to run MongoDB in their own data centers with full enterprise support, security, and operational tooling.
Atlas: The Cloud Bet That Rewrote the P&L
MongoDB Atlas, announced at MongoDB World in June 2016 and initially available on AWS, was the single most consequential product decision in the company's history. It was also the most dangerous. Launching a managed cloud service meant competing directly with the hyperscalers — AWS, Google Cloud, and Microsoft Azure — who could (and would) offer their own managed MongoDB-compatible services. It meant cannibalizing MongoDB's existing Enterprise Advanced business, where customers paid for licenses and support to run the database themselves. And it meant rebuilding the company's revenue model from the ground up: from upfront license fees and annual support contracts to usage-based consumption billing, where revenue scaled with the customer's workload rather than a procurement cycle.
Ittycheria made the bet anyway, and he made it early enough that MongoDB could build real differentiation before the hyperscalers caught up. Atlas offered something that AWS DocumentDB and Azure Cosmos DB could not: the full MongoDB query language, the full MongoDB feature set, and the guarantee that your application code would work identically whether you ran it on Atlas or on a self-managed MongoDB deployment. This was not a trivial distinction. Developers who built on MongoDB's API were locked into MongoDB's semantics — the aggregation pipeline, the document model, the specific behavior of reads and writes under various consistency configurations. A "compatible" service that approximated these semantics but didn't match them exactly was, for many workloads, useless.
The financial transition was painful. From FY2018 through FY2021, MongoDB's operating losses widened as the company invested aggressively in Atlas infrastructure, engineering, and sales. Atlas revenue, billed monthly based on compute and storage consumption, took longer to recognize than upfront license deals. The company's non-GAAP operating margins bottomed at roughly negative 18% in FY2020. Wall Street, characteristically, vacillated between panic and euphoria. But beneath the surface, the unit economics were transforming. Atlas customers expanded their usage dramatically over time — MongoDB's net ARR expansion rate consistently exceeded 120%, reaching 135% at its peak — meaning that a customer who spent $100,000 in year one would spend $135,000 in year two without any new sales effort. The consumption model turned every developer who started a small project on Atlas into a potential six- or seven-figure annual account as their application scaled.
By FY2025, Atlas accounted for roughly 68% of MongoDB's total revenue — up from less than 20% five years earlier. The transition was substantially complete. MongoDB had crossed the chasm from on-premise license vendor to cloud-native platform company, and it had done so while maintaining growth rates above 20% and reaching positive free cash flow. The P&L scars from the transition were real, but the strategic outcome was decisive: MongoDB now controlled the full customer relationship, owned the operational layer, and captured value in proportion to the workload's scale rather than a one-time procurement event.
MongoDB Atlas as a percentage of total revenue
FY2018Atlas launches broadly; represents ~10% of total revenue.
FY2020Atlas crosses 40% of revenue. Operating losses widen as cloud investment accelerates.
FY2022Atlas reaches ~57% of revenue. Net expansion rate holds above 120%.
FY2024Atlas at ~65% of revenue. Company approaches non-GAAP profitability.
FY2025Atlas at ~68% of revenue. Positive free cash flow for the full fiscal year.
The License That Broke the Internet
In October 2018, MongoDB did something that would reverberate through the entire open-source software industry: it changed its server license from the GNU Affero General Public License (AGPL) to a new, custom-drafted license called the Server Side Public License (SSPL). The SSPL added a single, devastating clause: anyone offering MongoDB as a service — that is, anyone who took the open-source code and ran a hosted version of it for customers — was required to open-source the entirety of their service management layer, monitoring tools, automation, and all ancillary software under the same license. In practice, this made it economically impossible for AWS, Google, or any cloud provider to offer a competitive managed MongoDB service using MongoDB's own code without either open-sourcing their entire proprietary cloud infrastructure or negotiating a commercial license with MongoDB.
The reaction was volcanic. The Open Source Initiative refused to recognize the SSPL as a genuine open-source license. Redis Labs had made a similar move months earlier with its Commons Clause, and Elastic would follow with the Elastic License in 2021 — but MongoDB's move was the most consequential because MongoDB was the most widely used database in the affected category. AWS, rather than accepting MongoDB's terms, built Amazon DocumentDB — a MongoDB-compatible service built on a proprietary Aurora-derived engine that implemented the MongoDB 3.6 wire protocol without using MongoDB's code. Google Cloud, facing the same problem, launched Firestore and enhanced its Cosmos DB competitor. The cloud providers had been put on notice.
Open-source purists were incandescent. MongoDB, they argued, had built its community and its market position on the backs of open-source contributors and users, then pulled the rug out when it suited the company's commercial interests. The argument had moral force. It also missed the strategic point. MongoDB's core thesis — validated by the experiences of Elastic, Redis, and later HashiCorp — was that the open-source business model was structurally broken in the cloud era. When a hyperscaler could take your open-source project, run it as a managed service, and capture the operational margin without contributing engineering effort or paying license fees, the open-source developer's value capture collapsed to zero. The SSPL was not a betrayal of open source. It was an acknowledgment that the economics of open source had been broken by the cloud, and MongoDB was choosing survival over ideology.
The results spoke for themselves. Amazon DocumentDB, while serviceable, never achieved feature parity with MongoDB. It lagged behind on the aggregation pipeline, on transactions, on Atlas Search, on vector search, and on the growing constellation of services that MongoDB bundled into its platform. Developers who built on MongoDB's full API found that DocumentDB was a downgrade, not a substitute. MongoDB Atlas continued to grow at rates that suggested AWS's competitive offering had barely dented demand. By 2024, MongoDB had demonstrated something that many thought impossible: you could build a durable, high-margin business on a formerly open-source database by controlling the license, owning the managed service, and maintaining feature velocity that outran any imitator.
The Aggregation of Everything
One of the underappreciated dimensions of MongoDB's strategy is how systematically it has expanded the database's functional surface area — turning what began as a simple document store into a platform that subsumes capabilities previously requiring separate specialized systems. This is the "developer data platform" vision that Ittycheria began articulating around 2020, and it represents MongoDB's most ambitious bet on where the company's long-term moat lies.
Consider the stack of features MongoDB has added to Atlas over the past five years. Atlas Search, built on an integrated Lucene engine, allows developers to run full-text search queries directly against their MongoDB data without maintaining a separate Elasticsearch or Solr cluster. Atlas Data Federation enables querying across MongoDB databases, AWS S3 buckets, and other data sources from a single query interface. Atlas Charts provides embedded analytics and visualization. Atlas Vector Search, launched in 2023, lets developers store and query vector embeddings directly in MongoDB — a capability that positions the database for AI/ML workloads requiring semantic search, retrieval-augmented generation (RAG), and similarity matching. Atlas Stream Processing, announced in 2023, adds real-time event processing capabilities.
Each of these features, individually, is a product that a venture-backed startup could build an entire company around. MongoDB bundles them into the platform at no additional cost (they consume Atlas compute and storage, which flows to revenue through the consumption model). The strategic logic is devastating in its simplicity: every additional capability that MongoDB absorbs is one fewer external system the developer needs to provision, connect, monitor, and pay for. The developer's switching cost rises with every feature they adopt. The operational simplicity of "one platform for everything" creates an inertia that no point solution can match, even if the point solution is technically superior for its specific use case.
Developers don't want to stitch together six different systems to build an application. They want one platform that handles their data — however they need to use it.
This is the aggregation theory of databases. Just as Google aggregated demand by owning the search interface, and Netflix aggregated content by owning the streaming interface, MongoDB is aggregating data functionality by owning the developer interface. The developer who starts with MongoDB for their document store discovers that they can also run search, analytics, streaming, and vector operations without leaving the platform. Each additional use case deepens the lock-in and expands the consumption footprint.
The AI Moment
When OpenAI released ChatGPT in November 2022, setting off the most intense infrastructure investment cycle since the cloud computing buildout, MongoDB was already positioned — somewhat accidentally, somewhat by design — at the intersection of AI and application development. The reason was structural: large language models are powerful reasoning engines, but they are useless without access to an application's proprietary data. Retrieval-augmented generation, the dominant architectural pattern for grounding LLM outputs in real-world data, requires a database that can store vector embeddings alongside operational data and query both simultaneously. MongoDB Atlas Vector Search, which the company had been developing since at least early 2023, offered exactly this.
The timing created a narrative tailwind that was almost too perfect. MongoDB's stock surged through mid-2023, driven by the AI hype cycle and the specific argument that MongoDB's document model — flexible, schema-free, capable of storing heterogeneous data types including vectors — was uniquely suited to the AI application stack. There was substance beneath the froth. The architectural argument was real: developers building AI-powered applications needed a database that could handle structured application data, unstructured text, and high-dimensional vector embeddings in a single system, and MongoDB was one of the few platforms that could do all three without requiring separate infrastructure.
But the AI tailwind also created new competitive pressures. Pinecone, Weaviate, Qdrant, and a constellation of purpose-built vector databases emerged, each claiming superior performance for pure vector search workloads. PostgreSQL added pgvector, leveraging the enormous installed base of Postgres to offer "good enough" vector capabilities without a platform migration. The hyperscalers added vector search to their own database offerings. MongoDB's bet — that developers would prefer an integrated platform over a best-of-breed point solution — was the same bet the company had been making since Atlas Search, but the stakes were higher.
By mid-2024, it remained too early to declare a winner. What was clear was that AI workloads were driving a new wave of application development, and every new application needed a database. MongoDB's developer adoption — the original competitive moat, the thing that had been true since 2009 — meant that a disproportionate share of those new applications would be built on MongoDB.
The Consumption Conundrum
The shift to consumption-based pricing, while strategically brilliant, introduced a new vulnerability that became painfully visible in late 2024 and early 2025. Unlike subscription models, where revenue is predictable and contractually committed, consumption revenue fluctuates with customer workload. When the macroeconomic environment tightened — when startups optimized their cloud spending, when enterprises rationalized their infrastructure costs, when the "optimize before you grow" mantra replaced "grow at all costs" — MongoDB's Atlas revenue growth decelerated. In Q3 FY2025 (the quarter ending October 2024), MongoDB reported Atlas revenue growth of approximately 26% year-over-year, down from 35%+ in the prior year. The stock dropped more than 20% in a single session.
The market's reaction revealed a structural tension in MongoDB's model. The same consumption dynamics that created extraordinary net expansion rates during boom times — developers scaling their workloads, adding new use cases, migrating more data — worked in reverse during downturns. Customers could reduce their Atlas consumption instantly, without canceling contracts or negotiating with sales. The elasticity that made Atlas attractive to developers made MongoDB's revenue inherently volatile relative to subscription-based enterprise software peers.
Ittycheria's response was characteristically direct. On the Q3 FY2025 earnings call, he acknowledged the consumption headwinds but pointed to underlying adoption metrics — new workloads, new customers, growing penetration within existing accounts — that he argued would drive re-acceleration as the spending environment normalized. He also emphasized that MongoDB was investing in capabilities (AI, search, streaming) that would expand the consumption surface area, creating new reasons for existing customers to increase their Atlas usage even in a constrained environment.
The debate about MongoDB's long-term growth trajectory centered on a single question: Was the deceleration cyclical (driven by temporary macro headwinds) or structural (driven by market saturation, competitive pressure, or the maturation of the developer adoption curve)? The answer, in truth, was probably some of both — and the ratio between them would determine whether MongoDB's next decade looked like Salesforce's (sustained premium growth on an expanding platform) or Oracle's (gradual deceleration as the installed base matured and pricing power diminished).
The Merriman Paradox
Dwight Merriman left his day-to-day operational role at MongoDB years ago but remained on the board and continued to hold a significant equity stake. Eliot Horowitz departed as CTO in 2020, after more than a decade of shaping the technical direction that made MongoDB what it was. The transition from founder-led to professional-CEO-led was smoother than most — Ittycheria's enterprise operating system was precisely what the company needed when he arrived, and the founders' continued involvement on the board provided continuity without the dysfunction that often accompanies the founder-to-CEO handoff.
But there's a paradox embedded in MongoDB's origin story that continues to shape its strategic position. Merriman and Horowitz built MongoDB because they were frustrated by relational databases. The document model was, explicitly, a rejection of the tabular schema that Oracle and PostgreSQL imposed. And yet, over the past decade, MongoDB has spent an enormous amount of engineering effort adding capabilities — transactions, joins, schemas (optional, via validation), SQL-compatible query interfaces — that make MongoDB behave more like a relational database. The company that was born to kill the relational model has survived by absorbing it.
This is not a contradiction. It is a strategy. MongoDB's thesis was never that the relational model was wrong — it was that the relational model was too rigid for the way modern applications are built. The document model, with its flexible schemas and nested structures, is the foundation. But by adding relational capabilities on top of the document model, MongoDB eliminates the trade-offs that once forced developers to choose. You can have flexible schemas and ACID transactions. You can have nested documents and joins. You can have developer speed and enterprise reliability. The aggregation of relational and non-relational capabilities into a single platform is, in many ways, the fulfillment of Merriman's original vision — not its betrayal.
Fifty Thousand Customers and the Long Tail
MongoDB's customer base, which surpassed 50,000 by 2024, exhibits a distribution pattern that reveals something fundamental about the company's competitive position. At the top, a relatively small number of enterprise accounts — estimated at 7,500+ with annual run rates exceeding $100,000 — generate a disproportionate share of revenue. These are the banks, insurers, telcos, and technology companies that run mission-critical workloads on MongoDB Enterprise Advanced or high-consumption Atlas deployments. At the bottom, tens of thousands of smaller customers — startups, mid-market companies, individual developers running side projects — consume Atlas at modest levels that collectively form a substantial revenue base.
The power of this distribution lies in the funnel. A developer who starts a free Atlas cluster for a hackathon project today is a potential six-figure enterprise customer in five years, as their startup grows, their application scales, and their data needs compound. MongoDB's sales motion is designed to accelerate this progression: community-led adoption at the bottom, self-serve Atlas onboarding in the middle, and a direct sales team that engages when usage crosses certain thresholds. The sales team's job, in many cases, is not to convince a customer to buy MongoDB — it's to help a customer who is already using MongoDB buy more of it.
This funnel converts at a rate that would make most enterprise software companies envious. MongoDB's dollar-based net retention rate — the metric that measures how much an existing cohort of customers spends year-over-year — has consistently exceeded 120%. In peak quarters, it has exceeded 135%. This means MongoDB's existing customer base alone, without any new customer acquisition, would deliver 20%+ annual revenue growth. New customer additions are growth on top of an already expanding installed base.
Our biggest competitor is not another database. It's Oracle and the installed base of relational workloads that haven't been modernized yet. That's a $100 billion TAM that we've barely scratched.
The Oracle comparison is instructive. Oracle's total database-related revenue (licenses, support, cloud) exceeds $20 billion annually. The global database market, broadly defined, is estimated at $80–100 billion. MongoDB's $1.8 billion represents less than 2% of this market. The bull case for MongoDB rests on the argument that every new application is a potential MongoDB workload, and that a meaningful portion of existing relational workloads — built on Oracle, SQL Server, and PostgreSQL — will eventually be modernized onto MongoDB's platform as the applications that depend on them are rewritten. The bear case is that PostgreSQL, which is free, open-source, and increasingly feature-rich (with JSON support, vector search, and a massive ecosystem), will capture the modernization wave at MongoDB's expense.
The PostgreSQL Question
If MongoDB has an existential competitive threat, it is not Amazon DocumentDB, which remains a pale imitation. It is not the purpose-built vector databases, which address a niche. It is PostgreSQL — the open-source relational database that has, over the past five years, undergone a renaissance that makes it arguably the most versatile database in the world. PostgreSQL now supports JSON/JSONB storage (enabling document-like workloads), full-text search, vector search via pgvector, time-series data, geographic data, and a plugin ecosystem that extends its capabilities in nearly every direction. It is free. It has an enormous and growing community. And it is available as a managed service from every major cloud provider (Amazon RDS/Aurora, Google Cloud SQL, Azure Database for PostgreSQL) as well as from specialized vendors like Neon, Supabase, and Tembo.
The PostgreSQL threat is not that it will replicate MongoDB's document model with perfect fidelity. It is that it will be "good enough" for a growing percentage of workloads while offering capabilities (native SQL, mature relational features, a vast ecosystem of tools and extensions) that MongoDB cannot easily match. For developers who don't need MongoDB's specific strengths — flexible schemas, horizontal scaling, the aggregation pipeline — PostgreSQL is an increasingly compelling alternative that avoids the lock-in of MongoDB's proprietary API.
MongoDB's defense against PostgreSQL is multi-layered. First, the developer experience: MongoDB's query language and document model remain, by most accounts, more natural for modern application developers than SQL. Second, the platform: Atlas's integrated search, vector, streaming, and analytics capabilities have no PostgreSQL equivalent that works as seamlessly. Third, horizontal scalability: MongoDB's sharding architecture, while complex to manage, scales to workloads that PostgreSQL cannot natively handle without third-party extensions like Citus. Fourth, the installed base: the tens of thousands of applications already built on MongoDB's API create switching costs that are real and growing.
But Ittycheria is not naive about the threat. MongoDB's investments in AI capabilities, in expanding Atlas's functional surface area, and in making the developer experience ever more frictionless are all, in part, responses to the gravitational pull of PostgreSQL. The game is to make MongoDB's platform so much more than a database — so integrated, so comprehensive, so operationally simple — that comparing it to PostgreSQL is like comparing Salesforce to a spreadsheet. The comparison is technically possible but strategically meaningless.
What the Document Knows
On a Tuesday morning in October 2024, a developer in São Paulo spun up a free-tier Atlas cluster, connected her Next.js application, and inserted her first document — a JSON object representing a user profile, with nested arrays for addresses and preferences, a vector embedding generated by OpenAI's API, and a geolocation field for the user's last known city. No schema. No migration. No DBA. The cluster auto-scaled as her application grew through its first 1,000 users, then 10,000, then — if the application found its audience — 100,000 and beyond, each expansion recorded as consumption revenue on MongoDB's income statement.
In Cupertino, a Fortune 100 technology company ran its device activation pipeline on a MongoDB Enterprise Advanced cluster, processing millions of events per hour with multi-document transactions that guaranteed exactly-once semantics. In London, a global bank used Atlas Vector Search to power a customer service chatbot that retrieved relevant account information using semantic similarity rather than keyword matching. In Tokyo, an automotive manufacturer stored sensor telemetry from connected vehicles in time-series collections, querying years of data with sub-second latency.
All of them — the solo developer in São Paulo and the Fortune 100 in Cupertino — were using the same query language, the same document model, the same database engine that Dwight Merriman and Eliot Horowitz began building in 2007 because they were tired of fighting Oracle at DoubleClick. The document that the São Paulo developer inserted and the document that the Cupertino engineer queried were, at the binary level, the same format: BSON. The distance between them — the entire seventeen-year arc of the company, the open-source wars, the license change, the cloud pivot, the transactions release, the AI moment, the $47 billion market cap — was encoded in the layers of capability that had accreted around that single, flexible, schema-free document. The data shaped itself to the application. It always had.
