The Need for Standardization in Document Databases: Moving Beyond "MongoDB-Compatible"

The database world is one of the areas in computing where we've seen tremendous evolution over the past decades. Relational databases, which once dominated the landscape, grew more versatile and powerful as they innovated around SQL as a standardized query language. This brought benefits like interoperability, reduced vendor lock-in, and transferable skills for developers. Today, document databases face a similar crossroads, and it's time to consider the value of standardization.

Many document database solutions tout their compatibility with MongoDB. Amazon DocumentDB, Azure Cosmos DB for MongoDB, and FerretDB all execute MongoDB-style queries and use MongoDB drivers. While this eases migration for those invested in MongoDB, it also fragments the ecosystem and limits growth. For instance, switching between "MongoDB-compatible" databases often reveals differences in behavior or unsupported features, requiring significant adjustments. This stifles innovation by forcing developers to resolve incompatibilities rather than build new features.

On the other hand, "the real MongoDB experience" is only available from a single vendor, MongoDB. The alternative products are attempting to save the user from this situation.

So what if, instead of being "MongoDB-compatible," document databases adhered to a unified standard for document storage, retrieval, and querying? This would be akin to what SQL has done for relational databases, providing a consistent foundation for users, developers, and vendors.

The Downsides of "MongoDB Compatibility"

Each document database solution that aims to be MongoDB-compatible does so in its own way, while attempting to mimic the MongoDB API. Despite the shared goal of compatibility, these products don't share the same feature set, and their behavior could be different from MongoDB.

This fragmentation limits developers. Moving between MongoDB-like systems is possible but often not seamless. Each "compatible" database has its own quirks, requiring testing and adaptation. Developers are essentially learning the nuances of different platforms under the guise of familiarity, leading to frustration and wasted effort. While these differences are present in the world of relational databases as well, they are more predictable and are often a result of the extension of the SQL standard.

Learning from SQL's Success

SQL's success can be attributed largely to its establishment as a standard language for relational databases. While different vendors (like MySQL, PostgreSQL, and Oracle) have implemented extensions, the core SQL syntax has remained standardized. This allows developers to transition between platforms and gives organizations the flexibility to choose vendors without being locked in. The standardization of SQL didn't stifle innovation—instead, it provided a common foundation upon which new ideas could thrive. Similarly, establishing a standard for document databases could promote interoperability and innovation, benefiting developers and vendors alike.

If document databases had a similar standard, switching between Amazon DocumentDB, Cosmos DB, FerretDB, or any other document-oriented database could be as seamless as switching between SQL databases. Developers could build skills with confidence, knowing their knowledge would apply across different products. This standardization could foster innovation, encouraging new vendors to enter the market without needing to mimic a proprietary API to gain traction.

The Document Database Standard

Creating a standard for document databases would involve defining a common query language, a consistent data model, and agreed-upon behavior for core operations. For example, a common query language similar to SQL but tailored for document databases could be established, allowing databases to use a JSON-like syntax with standard commands. This would address fragmentation by providing a unified way to interact with different platforms. Instead of being "MongoDB-compatible," these databases would adhere to a specification guaranteeing interoperability and consistency. This could involve forming an industry consortium, similar to how SQL was standardized, to define the future of document storage.

Such a standard could promote healthy competition, with each vendor focusing on optimizations, performance, and unique features rather than outdoing MongoDB in compatibility. This shift could also make it easier for newcomers to compete, pushing the industry forward.

A Call for Collaboration

The document database world is at an exciting juncture. With the rapid growth in unstructured data and the need for flexible storage solutions, document databases are becoming more critical. However, relying on "MongoDB compatibility" as the primary measure of success limits the potential of this technology.

Standardizing document databases, as was done with SQL, could unlock new opportunities for growth and collaboration. It would simplify migration between platforms and reduce the learning curve for developers, enabling them to focus on building innovative solutions rather than dealing with compatibility challenges. It’s time to move beyond "MongoDB-compatible" and work toward a future where document databases have a shared, standardized language—one that allows them to truly fulfill their potential.

We call on all vendors to come together and join the OpenDocDB Workgroup, an initiative dedicated to creating this new standard. By collaborating, we can establish a unified foundation that benefits developers, organizations, and the broader document database ecosystem.