Cosmos DB Request Units and Partitioning

5 minutes 5 Questions

Azure Cosmos DB is a globally distributed, multi-model database service that uses two fundamental concepts for managing performance and scalability: Request Units (RUs) and Partitioning. **Request Units (RUs):** Request Units represent a normalized measure of the cost of database operations in Cosmos DB. Every operation—whether it's a read, write, update, or delete—consumes a certain number of RUs. The cost depends on factors like item size, property count, data consistency level, query complexity, and indexing patterns. For example, a simple point read of a 1 KB item costs approximately 1 RU, while writes and complex queries consume more. You provision throughput in terms of RUs per second (RU/s). This can be set at the container or database level. Azure offers two provisioning models: **manual throughput**, where you set a fixed RU/s, and **autoscale throughput**, which automatically scales between a minimum and maximum based on demand. If your requests exceed provisioned RU/s, Cosmos DB will rate-limit (throttle) subsequent requests until capacity becomes available. **Partitioning:** Cosmos DB uses partitioning to horizontally scale data. Each container is divided into **logical partitions** based on a **partition key** you define. Choosing the right partition key is critical for even data distribution and optimal performance. A good partition key should have high cardinality and distribute reads/writes evenly across partitions. Logical partitions are mapped to **physical partitions**, which are managed automatically by Azure. Each physical partition can hold up to approximately 50 GB of data and handle up to 10,000 RU/s. As data grows, Cosmos DB automatically splits physical partitions to maintain performance. Queries that target a single partition (single-partition queries) are the most efficient. Cross-partition queries, which span multiple partitions, consume more RUs and have higher latency. Together, RUs and partitioning form the backbone of Cosmos DB's performance model, enabling predictable, scalable, and globally distributed data management.

Cosmos DB Request Units & Partitioning – Complete Guide for DP-900

Why Is This Important?

Azure Cosmos DB is Microsoft's globally distributed, multi-model database service and a cornerstone topic on the DP-900 (Azure Data Fundamentals) exam. Two of the most critical concepts you must understand are Request Units (RUs) and Partitioning. These concepts govern how Cosmos DB handles performance, scalability, and cost. Without a solid grasp of RUs and partitioning, you will struggle with exam questions related to Cosmos DB provisioning, throughput, pricing, and data distribution.


What Are Request Units (RUs)?

A Request Unit (RU) is a normalized, blended measure of the computational cost required to perform database operations in Cosmos DB. Think of it as a single currency that abstracts away CPU, memory, and IOPS into one easy-to-understand number.

Key facts about Request Units:

• A single point read (fetching one item by its ID and partition key) of a 1 KB document costs 1 RU.
• Writing, updating, deleting, and querying documents all consume RUs, but at different rates.
• More complex queries (those that scan multiple partitions, use aggregations, or process large documents) consume more RUs.
• RUs are measured on a per-second basis. When you provision throughput, you specify RU/s (Request Units per second).

Provisioning Throughput:

Cosmos DB offers two throughput provisioning modes:

1. Provisioned Throughput – You manually set the number of RU/s. This is ideal for predictable workloads. You can provision throughput at the database level (shared among all containers) or at the container level (dedicated to a single container). The minimum is 400 RU/s per container (or database when shared).

2. Serverless – You pay only for the RUs consumed by your operations. There is no upfront provisioning. This is ideal for development, testing, or workloads with unpredictable or intermittent traffic.

3. Autoscale – Cosmos DB automatically scales the provisioned RU/s between a minimum (10% of the max) and a maximum value you set. This is ideal for workloads with variable but somewhat predictable traffic patterns.

How RUs Affect Cost:

• You are billed based on the number of RU/s you provision (or consume in serverless mode) on an hourly basis.
• Over-provisioning wastes money; under-provisioning causes requests to be rate-limited (HTTP 429 errors).
• The Azure portal provides metrics and recommendations to help you right-size your RU/s allocation.


What Is Partitioning in Cosmos DB?

Partitioning is the mechanism Cosmos DB uses to horizontally scale data across multiple physical servers. It is essential for achieving high performance and virtually unlimited storage.

Logical Partitions:

• Every item in a Cosmos DB container has a partition key — a property you define when creating the container.
• All items that share the same partition key value belong to the same logical partition.
• A single logical partition can hold a maximum of 20 GB of data.
• Logical partitions are the fundamental unit of scope for transactions (stored procedures and triggers operate within a single logical partition).

Physical Partitions:

• Cosmos DB automatically maps one or more logical partitions to physical partitions.
• Physical partitions are the actual server resources (compute, storage, throughput) managed by Cosmos DB behind the scenes.
• Each physical partition can store up to 50 GB of data and handle up to 10,000 RU/s of throughput.
• You do not manage physical partitions directly — Cosmos DB handles splitting and merging automatically.

Choosing a Good Partition Key:

This is one of the most important design decisions when using Cosmos DB. A good partition key should:

• Have a high cardinality (many distinct values) — e.g., userId, deviceId, or tenantId.
• Distribute data evenly across logical partitions to avoid hot partitions (partitions that receive disproportionately more traffic or storage).
• Be used frequently in your queries' WHERE clauses to enable efficient, single-partition queries.

Examples of good partition keys: /userId, /tenantId, /deviceId
Examples of poor partition keys: /country (low cardinality), /createdDate (can create hot partitions for recent dates), a boolean field like /isActive (only two values)

Cross-Partition vs. Single-Partition Queries:

• A single-partition query targets one logical partition (the partition key is included in the query filter). This is the most efficient query type.
• A cross-partition query (also called a fan-out query) must query multiple or all partitions. These consume significantly more RUs and are less efficient.


How RUs and Partitioning Work Together

• Provisioned RU/s are distributed evenly across all physical partitions.
• If you provision 10,000 RU/s and have 5 physical partitions, each physical partition gets 2,000 RU/s.
• A hot partition can become a bottleneck — even if you have unused RU/s on other partitions, the overloaded partition may get rate-limited.
• This is why choosing a partition key that distributes both data and request volume evenly is critical.


Summary Table

Concept → Key Detail
Request Unit (RU) → Normalized cost of a database operation
1 RU → Point read of a 1 KB item by ID and partition key
Provisioned Throughput → Manual RU/s allocation (min 400 RU/s)
Autoscale → Automatic scaling between 10%-100% of max RU/s
Serverless → Pay per RU consumed, no provisioning
Logical Partition → Group of items sharing the same partition key value (max 20 GB)
Physical Partition → Server-managed storage unit (max 50 GB, 10,000 RU/s)
Partition Key → Property used to distribute data; must have high cardinality
Single-Partition Query → Most efficient; includes partition key in filter
Cross-Partition Query → Fan-out query; more expensive in RUs


Exam Tips: Answering Questions on Cosmos DB Request Units and Partitioning

1. Remember the RU baseline: A point read of a 1 KB document = 1 RU. Writes cost more than reads. Complex queries cost more than simple ones. If an exam question asks what consumes the fewest RUs, the answer is usually a point read by ID and partition key.

2. Know the throughput modes: Be able to distinguish between provisioned, autoscale, and serverless. Questions often present a scenario and ask which mode is most appropriate. Predictable workloads → provisioned. Variable workloads → autoscale. Dev/test or light workloads → serverless.

3. Understand rate limiting: When consumed RU/s exceed provisioned RU/s, Cosmos DB returns HTTP 429 (Too Many Requests). The solution is to increase provisioned throughput, use autoscale, or optimize queries to consume fewer RUs.

4. Partition key selection questions are common: If the question asks for the best partition key, choose the option with the highest cardinality that evenly distributes data. Avoid keys with very few distinct values.

5. Remember the limits: Logical partition max = 20 GB. Physical partition max = 50 GB and 10,000 RU/s. Minimum provisioned throughput = 400 RU/s. These numbers are frequently tested.

6. Single-partition queries are preferred: If a question asks about query efficiency or best practices, always favor queries that include the partition key in the filter.

7. Shared vs. dedicated throughput: Know that throughput can be provisioned at the database level (shared across containers) or at the container level (dedicated). Questions may ask when to use each approach.

8. RUs encompass everything: Do not confuse RUs with just CPU or just storage. RUs abstract CPU, memory, and IOPS into a single metric. If an exam question defines RUs, the correct answer will reference this blended/normalized concept.

9. Hot partitions cause throttling: Even with sufficient total RU/s, an uneven distribution of requests can cause throttling on specific partitions. Look for answer choices that reference partition key design when a question describes throttling despite adequate total throughput.

10. Watch for distractors: The exam may include options like DTUs (Database Transaction Units), which belong to Azure SQL Database, not Cosmos DB. Always associate RUs with Cosmos DB and DTUs/vCores with Azure SQL.

By mastering Request Units and Partitioning, you will be well-prepared to answer a significant portion of the Cosmos DB questions on the DP-900 exam with confidence.
Test mode:
Start practice test

DP-900 - Cosmos DB Request Units and Partitioning Example Questions

Test your knowledge of Cosmos DB Request Units and Partitioning

Question 1

What is the maximum storage capacity permitted for a single logical partition in an Azure Cosmos DB container?

Correct Answer: 20 GB of combined data and index storage

The key concept tested is Azure Cosmos DB partitioning limits.

A single logical partition in Azure Cosmos DB has a hard limit of twenty gigabytes for combined data and index storage to ensure optimal data distribution.

For the incorrect options, fifty gigabytes refers to the capacity limit of a physical partition rather than a logical one. Ten gigabytes and one hundred gigabytes are simply arbitrary storage values that do not reflect any valid Cosmos DB logical partition boundaries. Properly choosing a partition key prevents logical partitions from exceeding this maximum threshold.

Question 2

A team manages an Azure Cosmos DB container partitioned by 'TenantId'. Most users generate minimal traffic, but one major enterprise user is responsible for the vast majority of daily operations. The team observes intermittent rate-limiting on incoming requests from this enterprise user. Increasing the total provisioned Request Units for the entire container fails to resolve these rate-limiting events. What is the primary reason for this ongoing performance degradation?

Correct Answer: A single hot partition mapped to the enterprise tenant consumes its specific fraction of the total provisioned request units.

The correct answer is right because Azure Cosmos DB evenly distributes the total provisioned Request Units across all physical partitions, meaning a single highly active user creates a hot partition that is strictly limited by its specific slice of throughput capacity.
The alternatives are incorrect because database-level throughput provisioning does not force cross-partition limits. Also, strong consistency levels do not deplete a fictitious shared spatial request unit allocation. Finally, indexing policies automatically apply to the entire container rather than requiring manual updates for specific tenants.
The key concept tested is recognizing hot partitions and understanding Request Unit distribution in partitioned architectures.

Question 3

How does executing a cross-partition query affect Request Unit consumption compared to an identical single-partition query?

Correct Answer: The query incurs a significantly higher cost because the system executes operations across multiple separate physical boundaries.

A cross-partition query significantly increases Request Unit consumption because the database engine must execute the query operation across multiple physical storage boundaries and aggregate the results.
Cost is not identical because RU charges factor in execution overhead alongside payload volume. Distributed computation increases rather than lowers the operational cost since evaluating extra partitions demands additional compute resources. The base query processing charge is not divided to reduce consumption; instead, baseline overhead is accumulated from every partition the system must evaluate.
The key concept tested is the cost impact of partition strategies in Azure Cosmos DB.

More Cosmos DB Request Units and Partitioning questions
42 questions (total)
Start 42 question test

Other Describe Considerations for Working with Non-Relational Data on Azure concepts

Azure Blob StorageAzure Cosmos DB API for MongoDBAzure Cosmos DB API for NoSQLAzure Cosmos DB API for PostgreSQLAzure Cosmos DB APIs for Cassandra, Table, and GremlinAzure Cosmos DB Overview and Use CasesAzure Data Lake Storage Gen2Azure File StorageAzure Table StorageBlob Storage Access Tiers and LifecycleChoosing Azure Storage ServicesCosmos DB Consistency Levels
All Describe Considerations for Working with Non-Relational Data on Azure questions · DP-900 practice test