Reduce TCO with Azure Cosmos DB for MongoDB

Abinav Rameesh

Azure Cosmos DB for MongoDB is a fully managed MongoDB compatible cloud database service. Built on top of a proprietary engine to provide scale, performance and availability guarantees, the service eliminates the operational overhead of running self-hosted MongoDB instances.  

In this blog, we dig into seven specific reasons why total cost of ownership of your MongoDB database can be minimized with the vCore based offering for Azure Cosmos DB for MongoDB.

Separating the cost of Storage and Compute 

Although you can view Compute cluster tiers and their attached storage disks as a single entity replicated for scale and availability, Azure Cosmos DB for MongoDB de-couples the cost of each component. Storage remains cheap, even when attached to a Compute resource. Ensuring that the cost of Storage and Compute are not intertwined provides TCO optimizations by allowing compute heavy and storage heavy use cases to be priced independently and optimally. 

Tabulated below is the cost impact on a 16-core node, when its attached storage is scaled from 128GB to 4TB. 


Attached Storage Size (GB) % Price increased for Storage and Compute combined
256GB 1.1%
512GB 3.3%
1024GB 7.8%
2048GB 16.8%
4096GB 34%


Image Impact of Storage Scaling on Overall Cost


Despite a 32x increase in Storage from 128GB to 4TB, the cost of the cluster increases by just 34%. 

Large Disks for Storage Heavy Use Cases 

The vCore offering of Azure Cosmos DB for MongoDB now includes up to 32TB disks per shard (or node) in preview. Typically, storage heavy workloads had to overprovision Compute resources to meet minimum storage requirements. To reiterate, storage is cheap and should remain cheap when request volumes can be managed with fewer Compute resources. With large disks, storage heavy use cases will no longer need to provision more than the necessary amount of Compute just to meet their storage needs. 

Let’s consider a 200TB workload that previously used an M60 cluster tier (16-core) along with 4TB disks. Tabulated below are the number of Compute nodes needed when scaling from 4TB to 32TB of storage. 

Storage per node (TB) Number of nodes needed to meet storage needs
4TB 49
8TB 25
16TB 13
32TB 7


Image Reduction in Compute nodes with large disks

As we can see, the same 200TB workload can now save 85% on Compute costs with larger disks. Although you may need more than the minimum number of nodes to sustain the request volume of the cluster, the significant savings still stand out.

No Need for Storage Tiering 

Business verticals such as healthcare and finance must comply with mandates for long-term data retention. While only recent data is actively and heavily accessed, up to a decade of older data may need to be persisted. To save on cost, storage is tiered with hot data pushed to a transactional store and older, colder data archived to a cold store. This adds technical complexity, uneven performance, and multiple points of failure.   

With 32TB disks per shard now in preview and significant savings from large disks, both the hot and cold data can live in the transactional data store and avoid data archival to a disparate cold store. This also ensures consistency of performance regardless of the age of the data.

A Comprehensive SLA that Minimizes Time to Resolution

As a native managed cloud database service, Azure Cosmos DB for MongoDB covers the three tenets of the cloud – Compute, Networking, and Storage. Architecturally, the upper tier of the service is responsible for MongoDB compatible software that you would engage with as a user, while the lower tier is Azure’s bare metal infrastructure. Our SLA covers both the upper and lower tiers, unlike many third-party services that often exclude the lower tier.

While we strive to always be on, things can go wrong on occasion. As a managed service, all support incidents start and end with us and that’s what our SLA provides. We are responsible for the bare metal hardware as well as the database engine, thereby minimizing time to resolution (TTM) by avoiding re-routing across multiple teams. We are responsible for detection, mitigation, root causes analyses and everything in between.

You Don’t Pay Extra for Product Support

In addition, there is no added cost for product support. As an Azure customer, you will likely have a support agreement already, which also includes Azure Cosmos DB for MongoDB by default. 

Flexible Replica Configurations 

The service provides two replica configurations – one with High Availability enabled and another without. Disabling High Availability means fewer replicas and thus lower cost. Thus, lower environments can provision fewer replicas without high availability to minimize cost. 

No Licensing Costs 

Lastly and most importantly, you do not need to worry about timely license renewals as there are none.  

Key Takeaways

Azure Cosmos DB for MongoDB’s vCore-based offering effectively minimizes the total cost of ownership. By decoupling storage and compute costs, it allows for economically scalable solutions. The introduction of large disk capacities up to 32TB per shard caters to storage-heavy workloads, significantly reducing compute costs. The service eliminates the need for storage tiering, simplifying data management while ensuring consistent performance. With a comprehensive SLA, inclusive product support, flexible replica configurations, and no licensing costs, Azure Cosmos DB for MongoDB emerges as a robust, cost-effective choice for cloud database management.

Discover additional features about Azure Cosmos DB for MongoDB, explore the migration tool and get started for free today.

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless distributed database for modern app development, with SLA-backed speed and availability, automatic and instant scalability, and support for open-source PostgreSQL, MongoDB, and Apache Cassandra. Try Azure Cosmos DB for free here. To stay in the loop on Azure Cosmos DB updates, follow us on XYouTube, and LinkedIn.


Leave a comment

Feedback usabilla icon