Database-Level Throughput
← Back to DP-420 Terminology Reference
Category: Throughput & Scaling
Summary: Provisioned throughput shared across all containers in a database.
Overview
Database-level throughput is provisioned throughput shared across all containers within a database (rather than dedicated per container), useful when you have many containers with unpredictable or bursty individual usage but want to share a throughput budget across them, at the cost of less isolation between containers competing for the same RU/s pool.
More Info & Links
DP-420 Style Practice Questions
Q1. What is a key trade-off of using database-level shared throughput instead of container-level throughput?
- A. Containers share the same RU/s pool, so one busy container can consume RUs needed by others
- B. Database-level throughput always costs more
- C. Database-level throughput disables partitioning
- D. Database-level throughput cannot be used with autoscale
Q2. When might database-level throughput be a good choice?
- A. When you have many containers with lower, unpredictable individual usage that can share a throughput budget
- B. When you have one container requiring guaranteed dedicated throughput
- C. When you require the absolute highest performance isolation between containers
- D. When using the free tier exclusively
Answer Key
Answers are listed at the very end so you can attempt the questions first.
- Q1 (Database-Level Throughput): A. Containers share the same RU/s pool, so one busy container can consume RUs needed by others — With shared database-level throughput, one noisy container can consume RUs that other containers need, reducing isolation.
- Q2 (Database-Level Throughput): A. When you have many containers with lower, unpredictable individual usage that can share a throughput budget — Database-level throughput suits scenarios with multiple lower-traffic containers sharing capacity.
DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page
