App Dev Manager Paul King breaks down the concepts of Cosmos DB pricing for those new to the service.

My customers have spent some time working with Azure Cosmos DB and had questions around pricing. I thought I would share a bit of what I have learned when it comes to pricing for Cosmos DB for this BLOG article.

It’s important to note that things tend to change rapidly in the cloud and current Cosmos DB pricing information can always be found here.

Azure Cosmos DB vs On-Prem and IaaS

On-prem solutions are expensive. On-Prem solutions require physical locations for data centers to house the hardware, electricity for heating/cooling, servers, networking, storage and licensing. All of this is for each data center! IaaS DB implementations reduce the cost for the data center and electricity, but still require the licensing, networking, VMs and storage to run the solution. As a fully-managed database service, Azure Cosmos DB simplifies billing by charging only for provisioned throughput and consumed storage. There are no additional license fees, hardware, utility or facility costs. When you consider the multi region capabilities of Azure Cosmos DB, this reduction in cost is a substantial savings of existing on-prem solutions.

Azure Cosmos DB’s pricing model – Provisioned Throughput and Consumed Storage

Azure Cosmos DB’s pricing is based on hourly provisioned throughput and consumed storage.

Azure Cosmos DB supports various APIs that have different operations, ranging from simple reads and writes to complex graph queries. Each request consumes request units based on the amount of computation required to serve the request. Request units are a normalization of the physical dimensions of CPU, memory, and IO usage for every database operation. The number of request units for an operation is deterministic; you can track the number of request units that are consumed by any given operation in Azure Cosmos DB by looking in the response header. Additionally, we have an Azure Cosmos DB request unit calculator available to help you estimate costs. To provide predictable performance, you should provision throughput in units of 100 RU/second.

In Azure Cosmos DB, you can provision throughput in two different granularities; containers and databases. Azure Cosmos DB Containers is either a collection, table or graph depending on the API you are using to store your objects. Azure Cosmos DB database is a container of all the containers shared within that database. Provisioning your throughput ahead of time reserves this amount of performance for your solution that is backed by Azure Cosmos DB SLAs. Reserving or provisioning throughput ahead of time eliminates the “noisy neighbor effect” on your performance; by provisioning throughput ahead of time, Azure Cosmos DB will always have that amount of performance available to your application at any given time.

Since you are billed for all throughput provisioned, matching your provisioning to your needs can help you avoid charges for unused throughput. You can scale your provisioned throughput up or down as needed. One of the areas we encourage scaling throughput up is when you ingest data during a migration procedure. Once you have completed the migration, you should scale throughput down to handle the solutions’ steady state. Another place for scaling is when you have a site that peaks during normal business hours. You can scale up during your business hours and then scale down when you are outside of them. Our billing is currently at the granularity of one hour, so you will not save any money if you change your provisioned throughput more often than one hour at a time.

How is consumed storage calculated?

Storage is billed by GBs of SSD-backed storage used by your data and indexing. Automatic indexing that has not been tuned through policy (see below) is about 50% of the record size. The total storage used is the total storage of data and indexes used across all selected regions you are using for Azure Cosmos DB. If you are replicating Azure Cosmos DB into 3 regions, you will pay for that total storage cost in each of those three regions. Additional estimating assistance on storage can be found with our storage calculator.

Impacting RUs consumed by tuning the index policy

By default, Azure Cosmos DB automatically indexes every property of every record. This is intended to ease development and ensure excellent performance across many different types of ad-hoc queries. If you have large records with thousands of properties, you may find that paying the RU cost for indexing every single one of those properties may be wasteful, especially if you only query against 10 or 20 of those properties. As you get closer to getting a handle on your specific workload, our guidance is to tune your index policy. Full details on Azure Cosmos DB index policy can be found here.

Azure Cosmos DB Reserved Capacity Model

Azure Cosmos DB reserved capacity model is an upfront commitment on requests units needed over time. The discounts are tiered such that the more request units you use over a longer period, the more your discount will be. These discounts are applied immediately. Any RUs used above your provisioned values are charged based on the non-reserved capacity cost.

I hope this helps those who are new to Azure Cosmos DB gain a better understanding of how pricing is determined. Leveraging the Azure Cosmos you pay for the service at a significant savings over hosting your own solutions in either a data center or IaaS VMs.