If you have been wondering whether the tipping point for database-as-a-service (DBaaS) has arrived, it’s instructive to look at the success of MongoDB Atlas. In the 3 years since Atlas was launched, it has already exceeded $100 million in annual revenue, and now accounts for 34% of MongoDB’s revenue. MongoDB be claims to have more than 11,000 Atlas customers, although some 4,000 of those were acquired from its recent mLab acquisition.
Traditional database vendors such as Microsoft and Oracle are seeing much more modest take-up of their cloud DB offerings. MongoDB benefits from a lower level of entrenched on-premise deployments than these veteran databases, and also benefits from being associated with more modern web-based applications which are largely cloud-native.
Although at first glance it may seem questionable economics to pay for a hosted database which can be freely deployed on-premise, Atlas offers a compelling value proposition. For most deployments, the annualized cost of an Atlas subscription is much lower than the cost of even a single DBA. And when you consider that the subscription also includes all hardware costs, it can simply be cheaper to run MongoDB on Atlas than on-premise using an open source license.
An Atlas deployment also incurs less risk. The high availability features of Atlas are very robust. By default, an Atlas cluster will failover between multiple availability zones within a cloud provider’s region, and can easily be configured to failover across regions as well. Point in time recovery—a notoriously complicated process for an on-premise deployment—is built into the Atlas service and can be enabled by selecting a checkbox (and paying a little bit more).
Atlas is supported on all of the three major cloud platforms—Amazon, Microsoft Azure, and the Google Cloud Platform—allaying concerns of vendor lock-in that may arise when using a database service maintained by one of these providers.
Compared with an on-premise deployment, an Atlas cluster is far easier to scale. In most cases, increasing the resources available to the cluster is a simple operation requiring only a few clicks—providing you are willing to accept the increased hosting bills.
The global deployment capabilities of Atlas are particularly striking. It is possible to maintain a sharded Atlas cluster that routes data to globally distributed geographical regions. This allows one integrated database to span the globe while still maintaining data locality and sovereignty. By keeping data close to the customer, latency is reduced and performance is improved. Perhaps as importantly it is possible to comply with data sovereignty rules. If local legislation requires that certain data reside within a region—such as the European Union—then, these routing rules can achieve that outcome.
This is all pretty impressive, especially considering that MongoDB’s underlying architecture is not inherently geared toward elastic scalability on a global scale. Databases such as Cassandra and DynamoDB have a masterless architecture that in theory provides better reliability and efficiency for a globally distributed system.
However, MongoDB’s solution, while theoretically less sophisticated, appears to be sufficient to meet the demands of a rapidly growing MongoDB user base. It’s true that in a MongoDB global deployment the majority of nodes will function either as warm standbys or read-only secondaries. But, for many applications, this simply doesn’t matter. MongoDB’s popularity with developers, together with an increasingly mature cloud offering that scales to the needs of all but the very most demanding applications is proving to be more than adequate.