Branded as Microsoft’s “planetary scale database,” Cosmos DB is one of Azure’s foundational services, powering its own applications as well as yours. Designed for distributed application development, Cosmos DB offers a range of consistency models and, more interestingly, a series of different personalities that allow you to use it like any one of a set of familiar databases.
These include a PostgreSQL-compatible API, a graph database like Neo4j, and its own document database model, as well as support for the familiar Apache Cassandra distributed database. One of the more popular personalities is a set of APIs that aim to offer most of the features of the popular MongoDB NoSQL database. This last option is an interesting one, as it allows you to quickly take existing on-premises modern applications and quickly bring them to the cloud, ready for re-architecting on a global scale.
Jump to:
Understanding Request Units billing costs in Cosmos DB
There’s one issue that often confuses developers coming from a more traditional development environment: Cosmos DB uses the concept of Request Units to handle billing, in addition to Azure’s standard storage charges.
An RU is a way of describing and charging for how a database like Cosmos DB uses Azure resources. It brings together compute, I/O and memory, using the resources to make a 1KB read of a single item as the base of what can best be thought of as Cosmos DB’s own internal currency.
With a single read of a single item measured as 1 RU, all other operations are billed in a similar way, bundling their actions and resource usage as a value in RU. You purchase bundles of RU that are then spent in database operations, much like buying tokens for a game like Roblox. RU can be used to manage operations, with a set number per second available for your operations or used to pay for serverless operations. You can also use RUs to allow your database to scale as needed, though this does mean a particularly busy application can suddenly become very expensive to run.
The RU model, while logical for a cloud-native service, makes it hard for you to predict the cost of running Cosmos DB if you’re used to traditional costing models. While it’s possible to build tools to help predict costs, you must account for more than just the operations your database uses, as the type of consistency model you choose will affect the available throughput.
Introducing vCores to Cosmos DB
Microsoft is now offering an alternative to the RU model for developers bringing their MongoDB-based applications to Cosmos DB. Instead of paying for RUs and storage, you can now choose to focus on the more familiar mix of application instances and assigned disks. This gives you access to a model that’s a lot closer to MongoDB’s managed Atlas cloud service, allowing a more predictable migration from on premises or other clouds.
Available as Azure Cosmos DB for MongoDB vCore, this new release of Microsoft’s NoSQL database is a full-fledged part of your Azure infrastructure that gives you automated sharding and integration with Azure’s Command-Line Interface and other management tooling.
Microsoft describes it as a way to “modernize MongoDB with a familiar architecture.” The aim is to deliver as close as possible a set of compatible APIs, while still offering scalability. For example, Microsoft told us,
“Azure Cosmos DB for MongoDB vCore enables richer, more complex database queries such as the full-text searches that power cloud-based chatbots.”
Moving applications from MongoDB to Cosmos DB
If you have code using MongoDB’s query language to work with your data, it should work as before, with the main requirement being to change any endpoints to the appropriate Azure address.
However, not all commands are available on Cosmos DB, as the underlying features don’t map between the two databases. It’s worth paying attention to the list of supported commands, especially if you’re relying on MongoDB’s session control tooling, as much of this isn’t currently available in Cosmos DB. You’ll also have to switch any authentication to Azure’s native tooling.
Moving data between the two should be easy enough, as MongoDB’s export and import tools allow you to save data as either JSON for partial exports or the more compact BSON for a full database. If you’re moving a lot of data as JSON, this can be expensive, as you’ll be charged for data transfers.
Pricing is based on standard Azure virtual infrastructure, using either high availability or lower availability systems. If you don’t need an HA system, then you can save up to 50% on the HA pricing. Base storage for a vCore Cosmos DB system is 128GB, which should be suitable for many common workloads. You can choose to start with two vCPUs and 8GB of RAM and scale up to 32 with 128GB of RAM.
While most applications will work with little modification, like the RU version, the vCore release of Cosmos DB’s MongoDB support does have some differences from the official APIs. We asked Microsoft if there were plans to add more coverage in future releases, beyond the shift to vCore over serverless.
“In most scenarios, this makes the two technologies entirely compatible. Based on customer feedback, one of the larger pain points regarding compatibility between MongoDB and Azure Cosmos DB was the need to re-engineer and reshape their MongoDB databases to fit with how Azure Cosmos DB is architected. This release eliminates that pain point as the two databases are now essentially the same ‘shape.’ In addition, we have strong feature compatibility between the two and will continue to roll out more features as this moves out of preview and into general availability,” a spokesperson responded.
This new MongoDB option should make it easier to bring a MongoDB workload you’ve already written to Cosmos DB and thereby free yourself from having to run your own MongoDB infrastructure — or let you consolidate on using Cosmos DB as your cloud database, bringing databases from other cloud providers to Azure, where you can use all the other Azure resources and services that smaller providers like MongoDB don’t offer.
