Provisioned Throughput

From Ilianko
Revision as of 15:07, 26 October 2026 by Anko (talk | contribs) (Recreated DP-420 term page: Provisioned Throughput (Throughput & Scaling))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

← Back to DP-420 Terminology Reference

Category: Throughput & Scaling

Summary: Reserved, guaranteed RU/s billed regardless of consumption; suits steady workloads.

Overview

Provisioned throughput is a capacity mode in which you reserve a fixed amount of RU/s (request units per second) for a container or database ahead of time, guaranteeing that throughput is available and billed whether or not it's fully consumed. It suits predictable, steady-state workloads, and can be configured as standard (manual) or autoscale.

    | Current State                   | Target State                                  | Supported?         | How                                              |
| ------------------------------- | --------------------------------------------- | ------------------ | ------------------------------------------------ |
| Dedicated throughput container  | Different dedicated throughput value          | ✅ Yes              | Scale RU/s up or down                            |
| Shared throughput database      | Different shared throughput value             | ✅ Yes              | Scale database RU/s up or down                   |
| Manual throughput               | Autoscale throughput                          | ✅ Yes              | Convert throughput mode                          |
| Autoscale throughput            | Manual throughput                             | ✅ Yes              | Convert throughput mode                          |
| Database with shared throughput | Add new container that uses shared throughput | ✅ Yes              | Create container inside the database             |
| Database with shared throughput | Add new container with dedicated throughput   | ✅ Yes              | Create container and choose dedicated throughput |
| Dedicated throughput container  | Shared database container                     | ❌ No               | Must create a new container and migrate data     |
| Shared database container       | Dedicated throughput container                | ❌ No               | Must create a new container and migrate data     |
| Container in one database       | Move to another database                      | ❌ No               | Create new container and migrate data            |
| Dedicated throughput database   | Shared throughput database                    | ❌ Not applicable   | Throughput model is set at creation              |
| Shared throughput database      | Dedicated throughput database                 | ❌ Not a conversion | Create a new database and migrate                |

  

More Info & Links

DP-420 Style Practice Questions

Q1. What best describes provisioned throughput in Azure Cosmos DB?

  • A. A reserved, guaranteed amount of RU/s that is billed regardless of consumption
  • B. Billing based only on the exact number of RUs consumed with no reservation
  • C. A throughput mode available only for the MongoDB API
  • D. A mode that disables indexing to save cost

Q2. Which workload pattern is best suited for provisioned (standard) throughput?

  • A. Predictable, steady-state traffic
  • B. Highly unpredictable, spiky, low-volume traffic
  • C. Development-only workloads with near-zero traffic
  • D. One-time data migration jobs only

Answer Key

Answers are listed at the very end so you can attempt the questions first.

  • Q1 (Provisioned Throughput): A. A reserved, guaranteed amount of RU/s that is billed regardless of consumption — Provisioned throughput reserves a guaranteed RU/s capacity that is billed whether or not it's fully used.
  • Q2 (Provisioned Throughput): A. Predictable, steady-state traffic — Provisioned throughput fits predictable, steady workloads where a fixed RU/s reservation makes sense.

DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page