Azure Cosmos DB is a highly-scalable database service that supports multiple database backends including MongoDB, Cassandra, SQL, and more. Using Cosmos DB, you configure the desired throughput for your database in Request Units (RU), which are consumed by read and write operations to your database. 

    Blue Matador automatically monitors the total amount of RU that is being consumed in each of your Cosmos DB Accounts against the configured amount using the TotalRequestUnits and ProvisionedThroughput metrics. When usage approaches the provisioned amount, an event is created.


    Consistently operating near your RU limit on a Cosmos DB Account will cause an increase in throttled (HTTP 429) operations. Throttling can have a severe impact on application performance as the requests need to be retried. It’s important to note that some request throttling should be expected from Cosmos at any time, even when not operating near the provisioned RU amount; this is just the nature of highly-scalable and distributed databases. 



    The general fix when reaching your RU limit is to provision more RUs for the collections or databases than need it. Before simply adding more RU, you should first ensure that it is the correct course of action. 



    If at all possible, look at the queries you are making through Cosmos to see if optimizations can be made. The amount of RU used in a request is affected by the following properties:

    • Item size
    • Item indexing
    • Number of properties in an item
    • Number of indexed properties in an item
    • Consistency: strong and bounded staleness consume more RUs when reading
    • Number of query results
    • Number of query predicates
    • Size of both the source set and result set
    • Projection of query results

    The costs of requests in Request Units does not scale linearly with item size. Azure provides the following table to roughly explain how requests of different size will translate into RU usage:

    Item Size

    1 Read

    1 Write

    1 KB

    1 RU

    5 RUs

    100 KB

    10 RUs

    50 RUs

    While it is cheaper to operate on smaller items, for certain data types it may make sense to batch operations together to achieve higher throughput. For example, it takes fewer RU to read an array with 100x 1kb items than to perform 100 read operations to read them separately. 



    Data stored in Cosmos DB is partitioned to allow for increased redundancy and scalability. Every collection has a defined partition key which is used to organize items into partitions. With a poorly-chosen partition key, you can end up with one or more hot partitions where the majority of requests go to a single partition. This usually results in a very inefficient use of RUs and will make it harder to scale up your throughput. If your data does not inherently contain a good partition key, read up on creating a synthetic partition key or consider storing this data elsewhere.