The EDB Blog

January 10, 2019

Yesterday, AWS launched Amazon DocumentDB, which they describe as “a fast, scalable, and highly available document database that is designed to be compatible with your existing MongoDB applications and tools.”1 Look out MongoDB! Your popular DBaaS offering, Atlas, will now have to compete with Amazon on its home turf.

This is an interesting development, especially considering that MongoDB recently changed their licensing terms specifically to prevent mega cloud service providers like AWS from swooping in and profiting from the development they’d invested in their open source project. MongoDB’s new Server Side Public License (SSPL) includes “an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service.”2 Of course, since Amazon’s new offering is simply providing a compatible set of APIs on top of their own new database offering and is not reusing the MongoDB source code itself, this restriction doesn’t apply.

Even worse, it looks like MongoDB may have lost on two counts. Not only has the SSPL failed to prevent Amazon from offering a MongoDB compatible database service, but their new license terms seem to have backfired in the open source community, as well.

Last month, Debian dropped MongoDB from it’s Debian archive, while Red Hat removed MongoDB from the Red Hat Enterprise Linux (RHEL) 8.0 Beta. These moves were in response to the terms of the SSPL, which were deemed contrary to the spirit of open source.

Adding insult to injury, AWS implies in their product description that MongoDB out-of-the-box simply lacks the performance, scalability, and availability that enterprises needs to operate mission-critical workloads at scale. AWS’s new offering is being presented as solution to offer all the benefits of MongoDB, with none of its shortcomings.3 And, by implementing the Apache 2.0 open source MongoDB 3.6 API, AWS has made their offering MongoDB compatible. This is interesting, although not terribly complicated, as MongoDB compatibility certainly presents a lower bar than than Oracle compatibility, in my opinion.

I will note that you don’t have to get on the AWS train or be locked into MongoDB’s proprietary future if you want a MongoDB compatible API. I’d recommend that you take a look at ToroDB with PostgreSQL compatibility. And since it’s backed by a robust RDBMS like PostgreSQL, you’ll get the performance, scalability and availability that Amazon is promising in their new offering, and have the bonus of also being able to query your data with SQL.

So, what does this mean for users going forward? Matt Asay, a former VP of community at MongoDB says, “For customers, this basically means they can get their MongoDB from AWS as a cloud service. But what it means for AWS, and for MongoDB, is much more complex."4

Personally, I can certainly relate to MongoDB’s desire to protect their investment in developing the MongoDB project. At EDB, we invest a tremendous portion of our development effort into making community PostgreSQL the best open source RDBMS in the industry and it can be frustrating to see mega cloud service providers profiting richly from these efforts. On the other hand, this is to be expected in the new reality of the public cloud and open source.

1 -

2 - 

3 -

4 -

Ken Rugg is EDB's Chief Product and Strategy Officer and is charged with leading the company's product and strategic vision. Prior to joining EDB, Ken was the founder and CEO of Tesora. The Tesora DBaaS Platform, based on OpenStack Trove, let enterprises provide self-service database...