MongoDB’s recent and well-publicized new license—the Server Side Public License (SSPL)—was explicitly designed to prevent cloud vendors such as Amazon from deploying a MongoDB cloud service without paying MongoDB license fees.
While the license does not prohibit the use of the open source MongoDB code by a cloud services vendor, it does require that vendor to open source all the infrastructure code required to deploy the service. In practice, this prevents a vendor such as Amazon from utilizing the MongoDB open source edition, since no cloud vendor is likely to open source its proprietary infrastructure code.
In early January, Amazon announced DocumentDB, a MongoDB-compatible cloud database service. While this might have appeared to have been a response to MongoDB licensing changes, the reality is that this new service must have been in development for some time. The new offering uses no MongoDB source code, and the API is based on the MongoDB 3.6 release, which predates the SSPL versions of MongoDB.
Amazon implies that this new database offering is in response to requests from customers running MongoDB on Amazon’s cloud services. They say that while customers are happy to use the MongoDB database model and API, they struggle to build highly scalable MongoDB clusters. This may be true, although MongoDB’s own database as a service offering—Atlas—provides a solution to this problem that would satisfy most customers.
It is unlikely that diehard MongoDB developers will find Amazon’s offering particularly satisfying. It may offer superior performance and scalability to MongoDB deployed on-premise, and it may—or may not—offer advantages over MongoDB’s own Atlas cloud service. However, it offers lackluster support for the full set of MongoDB capabilities. It does not support any of the newer features in MongoDB 4.0 such as transactions or the change stream capability. And, while DocumentDB claims MongoDB 3.6 compatibility, many significant features in 3.6 are not supported. For instance, it is not possible to perform joins in aggregation commands ($lookup and $graphLookup) and almost half the aggregation frameworks functions are missing. Basic CRUD (Create-Read-Update-Delete) operations are reasonably well supported, however.
Amazon is not the first cloud vendor to provide a MongoDB-lookalike service. Microsoft’s CosmosDB has provided a MongoDB-compatible API for some time. As with Amazon’s DocumentDB the Azure service translates MongoDB API calls into database requests compatible with the underlying core database service. To date Cosmos DB has achieved relatively modest take-up: It ranks number 27 on the DB–engines.com site.
Amazon’s DocumentDB database has attracted a lot of attention. However, if I were a MongoDB executive, I would not be particularly concerned. The product offers little more than token compatibility with MongoDB and requires a fairly strong commitment to the Amazon Cloud. The alternative MongoDB Atlas offering is portable across clouds (GCP, AWS, Azure) and offers perfect MongoDB compatibility.
The increasing adoption of the MongoDB API by external vendors may suggest something of greater long-term significance for the database industry. It’s looking increasingly likely that the MongoDB API is destined to become the SQL of the document database world. SQL succeeded because it provided a sort of lingua franca for databases: a common language that was supported by all vendors. SQL itself remains a common language for analytics, supported by virtually all database systems. But inside application code, non-SQL APIs are the new normal, and for document databases the MongoDB API is definitely the front-runner.