When creating a Cosmos DB account, if you choose the Provisioned pricing model, you can set the number of RUs that your storage account will use in increments of 100 RUs per second, with the minimum being 400 RUs.

By setting a defined number of RUs, you can precisely control and predict your costs; however, if your solution is continually using up your RUs, performance will be impacted. Note that setting 400 RUs means you are billed for that number of RUs, whether you use them or not.

When choosing the provisioned throughput model, you therefore have a few additional options to help manage performance and costs. The first is that RUs can be set at the database level or at the container level.

Tip

A Cosmos DB container is synonymous with a table. Although you can store different record types in a single container, separating out different record types is useful to help manage costs and performance.

Using the database level ensures all operations are equal in performance across all records and also ensures you don’t incur additional costs as additional containers are added. However, if you set RU limits at the container level, you can vary the performance of different containers. For example, you could put the minimum RUs on some containers that you know are not used much, but have a higher RU rate for containers that do require more throughput, as in the following example:

Figure 12.4 – Using different RU rates on other containers

As your application grows, you may need to increase the number of RUs your databases or containers consume. If this growth can be predicted, the standard provisioning described earlier is a good fit. However, if your applications experience variable usage through the month—for example, if certain days are busier than others—you have the option of provisioning your Cosmos DB account with autoscale.

With autoscale, you define an upper limit to the number of RUs your application can use, and your Cosmos DB account will automatically scale up to meet those needs. This option is ideal for critical or variable workloads; however, the minimum starting point is 4,000 RUs. Therefore, if your application is small, manual scaling may be preferable.

The other pricing option when provisioning Cosmos DB is Serverless.

Serverless throughput

In some ways, serverless throughput takes the autoscale option to the next level. With serverless, you do not define any minimum or maximum limits. Your Cosmos DB account will simply use the number of RUs required to perform at peak capacity.

This is an excellent option for applications that may spend long periods of time idle or at low usage but need to be able to burst performance on demand.

The downside of serverless is that you have no control over upper limits, which means that if your database is continually at high usage, your costs would be equally high and uncontrolled.

At the time of writing, serverless is in preview in some regions, and as such, there are certain limitations. One such constraint is that the maximum storage per container is 50 gigabytes (GB). When the service goes out on general release, this may be lifted.

Although both Cosmos DB and Azure SQL services can be easily scaled, you still need to factor in future growth and how that might happen. In the next section, we will look at the different options for scaling your database services.