As great as MongoDB’s recent quarter was (and it was great), what’s even better might be the very thing some people think could harm its future quarters: the new Linux Foundation–hosted DocumentDB. Billed as “a fully open source, MongoDB-compatible document database,” DocumentDB has the potential to move developers off MongoDB. But that’s not the whole story. DocumentDB also gives MongoDB a chance to ride an industry-funded effort to popularize its approach to modeling data, which it needs to successfully confront the increasingly popular Postgres.

As MongoDB veteran Mat Keep puts it, “This is … a great opportunity for MongoDB to establish its API as … the NoSQL standard.”

MongoDB’s go-it-alone approach is losing steam against the community momentum of Postgres and has yet to make a dent in the SQL standard bearer. If MongoDB wants to compete with an open, portable default while dramatically increasing its total addressable market, it needs its own version of an open, portable default. Enter DocumentDB.

DocumentDB and gravity

The Linux Foundation’s DocumentDB is a new open source project Microsoft launched earlier this year and has now donated to the LF. No, it’s not related to the Amazon DocumentDB service though, somewhat confusingly, that team has pledged its support for this related-but-unrelated DocumentDB initiative. It aims to provide a permissively licensed, MongoDB-compatible, Postgres-based document database. It also plans to establish an open standard around document APIs and behavior. AWS has already joined the project’s technical steering committee, Google is publicly supportive, and the project’s charter language frames conformance and cross-vendor portability as central goals. The ultimate goal is to establish an “open standard for document-based applications [just] like what SQL did for relational databases,” as LF Executive Director Jim Zemlin notes.

That’s a big tent, not a little fork. But is it also a big problem?

MongoDB’s problem is gravity, not any particular cloud provider. Postgres has become the “safe” default for developers. It benefits from decades of standardization (SQL/ISO 9075), conformance expectations, and a large toolchain that treats Postgres as table stakes. Standards reduce risk and switching costs; ecosystems accrete around standards. If MongoDB wants to stop Postgres from swallowing more of its potential greenfield, it needs to lower switching costs into the MongoDB way—not just into MongoDB’s cloud service (Atlas).

This really isn’t controversial—it’s history. If you were building applications in the ’80s and ’90s, the rise of SQL as an ANSI standard and an ISO standard did three things that mattered to developers and enterprises:

• Portability of skills and code: Knowing SELECT, JOIN, and transactions wasn’t a vendor bet; it was a career bet. You could move between vendors without relearning the basics. Enterprises could hire for “SQL” rather than “vendor X DSL.”
• Predictability across vendors: Standards didn’t erase differences, but they created enough common ground for architects to plan long-lived systems with lower lock-in risk. Tools exploded because the “center” was reliable.
• Room for differentiated excellence: Vendors competed on performance, operations, security, ecosystem, and management tools—not on whether GROUP BY existed.

Oracle didn’t fight that tide; it led and rode it. (Disclosure: I work for Oracle and I worked for MongoDB twice.) Oracle shipped the first commercially available SQL RDBMS and then out-executed with cross-platform portability, performance, and operations to match enterprise needs. The standard expanded the market; as the SQL standard bearer, Oracle captured a huge share by delivering the best managed experience and surrounding ecosystem. There’s a lesson here for MongoDB.

Helping yourself by helping others

A standard lowers barriers for everyone. That can feel uncomfortable if your strategy depends on proprietary control. Yet encouraging standards is precisely how you grow a category you’re best positioned to win. MongoDB has spent hundreds of millions of dollars on R&D, but Postgres sees multiples of that in collective investment across the industry. A stronger marketwide document standard should help even this investment imbalance, growing the overall document database pie, with MongoDB poised to earn a big slice of those workloads precisely because of its investments in brand and product.

To put it more bluntly: Control is finite; influence is compounding. SQL didn’t kill Oracle or SQL Server—it made them bigger businesses. Kubernetes didn’t commoditize cloud—it redirected competition toward managed experience, security, and reliability. The same dynamic is available to MongoDB.

Of course MongoDB won’t be the only vendor that benefits, but that’s a feature, not a bug. AWS, Google, and others are piling into DocumentDB because they, too, hope to benefit (and will invest commensurate with those expected returns). My employer, Oracle, hasn’t announced support for the standard, yet Oracle would also benefit. Oracle Database 23ai introduced JSON Relational Duality, which lets developers present and update the same underlying relational data as updatable JSON documents—without duplicating data—and access it through MongoDB-compatible APIs, REST, and SQL. It’s very cool. Standards tend to enable this kind of “have it both ways,” and ecosystems tend to amplify it. If a neutral document standard nails API behavior and semantics, vendors can innovate on how they store and optimize data beneath that API—exactly what Oracle is doing by unifying document and relational on one engine.

Otherwise stated, when the surface area (the developer experience and API) is predictable, buyers choose based on operational excellence, scale, governance, and adjacent capabilities (analytics, AI, security). That’s where MongoDB has invested for a decade with Atlas. A standard doesn’t erase that; it spotlights it.

The alternative is to keep fighting gravity with licensing. That path demonstrably shrinks distribution and goodwill. DB-Engines trend lines show Postgres’ sustained ascent and MongoDB’s relative flattening since it switched from open source to the Server Side Public License—even as MongoDB the company executed brilliantly on monetization. You can win revenue battles and still lose the platform war.

Have the standards cake and eat it too

MongoDB doesn’t have to surrender control of its road map to gain the benefits of standardization. In practice, the company can trade a little control for a lot of influence.

Put compatibility where it counts: the spec and the tests. MongoDB already runs deep conformance suites internally. Donating a subset of those as a vendor-neutral conformance test harness focused on core CRUD, query semantics, indexing behavior, and error handling would frame MongoDB as the standard bearer while preserving room for commercial differentiation (e.g., advanced aggregation, Atlas Search, online archiving, vector features). A tiered conformance program (core, extended, enterprise) would mirror how Cloud Native Computing Foundation or SQL standards work in practice.

Lead the driver story. The Linux Foundation project aims for “100% compatibility with MongoDB drivers.” MongoDB can help by clarifying driver expectations (wire protocol nuances, retry semantics, change streams) and by coauthoring neutral driver conformance docs. This protects developers from subtle incompatibilities while reinforcing MongoDB’s role as the reference implementer of the “MongoDB way.”

Champion a migration-friendly baseline. Where the market needs stability—IDs, BSON types, index behavior, error codes—MongoDB can favor predictability over cleverness. The standard can define these without freezing MongoDB’s innovation. The history of ANSI SQL is instructive: Standardize 80%, innovate 20%, and either bring the best ideas back into the standard or keep them as value-added extensions.

Use neutrality to your advantage. Developers trust vendor-neutral governance. The Linux Foundation sets up a technical steering committee and charter that encourage multi-vendor stewardship and transparent decision-making. MongoDB should seek involvement, contribute clearly scoped artifacts (tests and specs), and help shape a compatibility “profile” that balances pragmatism with fidelity to the MongoDB model. Again, influence is greater than control.

Differentiate where customers feel it. Standards grow markets, and experiences win deals. Keep doubling down on Atlas’s operational excellence, security, AI integrations, data tiering, multi-region resilience, and “whole app” tooling around the document model. The goal isn’t to prevent anyone else from “speaking MongoDB”—it’s to ensure that when they do, Atlas still feels better.

If DocumentDB succeeds in establishing a credible, neutral standard for document databases, two things happen: First, the market for document-first design grows. Architects get the predictability they crave and the skills portability their teams demand. That draws workloads that would otherwise default to some flavor of SQL/relational. Second, MongoDB’s comparative advantages compound. With the friction of trying document modeling reduced, more teams will evaluate MongoDB Atlas.

MongoDB has spent years ensuring it captures most of the existing document database pie. The DocumentDB moment is a chance to grow that pie. Embrace the standard. Help write it. Lead it. Compete—confidently—on the experience the company can deliver at scale.

If MongoDB doesn’t help define the open document standard, Postgres will keep developers firmly in the SQL/relational camp. And that’s the only outcome MongoDB truly can’t afford.