What is read and write capacity in DynamoDB (provisioned vs on-demand)?
Understand DynamoDB read and write capacity: how provisioned and on-demand modes differ, when to use each, and how to avoid throttling and overpaying.
Expected Interview Answer
Read and write capacity is how DynamoDB meters and bills the throughput your tables consume, and it comes in two modes: provisioned, where you reserve a fixed number of read/write capacity units, and on-demand, where DynamoDB auto-scales and charges per request.
In provisioned mode you set RCUs and WCUs up front (optionally with auto scaling) and pay for the reserved capacity whether or not you use it, which is cheapest for steady, predictable traffic. In on-demand mode you set nothing; DynamoDB instantly accommodates spikes and bills per read/write request, which suits unpredictable or new workloads. You can switch a table between modes, but only once every 24 hours.
- Provisioned mode gives the lowest cost for steady, predictable traffic
- On-demand mode needs zero capacity planning and absorbs sudden spikes
- Provisioned mode supports auto scaling and reserved-capacity discounts
- On-demand avoids throttling from under-provisioning
- Both modes can be mixed across tables in one account
AI Mentor Explanation
Provisioned capacity is like booking a fixed number of net-practice lanes for the whole season: you pay for those lanes even on days nobody bats, but the rate is cheap because it's reserved. On-demand is like renting a net by the hour only when players actually show up — no waste on idle days, but each session costs more.
Step-by-Step Explanation
Step 1
Estimate your traffic pattern
Decide whether request volume is steady and forecastable or spiky and unpredictable — this drives the mode choice.
Step 2
Choose provisioned for steady load
Set RCUs and WCUs to your expected throughput and enable auto scaling to handle moderate variance cheaply.
Step 3
Choose on-demand for unknown/bursty load
Pick on-demand for new apps, spiky traffic, or serverless workloads where you can't predict capacity.
Step 4
Right-size provisioned capacity
Use CloudWatch metrics and consumed-capacity graphs to tune RCUs/WCUs and avoid throttling or over-paying.
Step 5
Switch modes if needs change
Move between provisioned and on-demand as traffic matures, remembering the once-per-24-hour switch limit.
What Interviewer Expects
- Clear definition of RCUs and WCUs as throughput units
- Understanding of the trade-off between cost and elasticity
- Knowing provisioned suits steady traffic, on-demand suits spiky traffic
- Awareness of auto scaling in provisioned mode
- Knowledge of the 24-hour mode-switch limit
Common Mistakes
- Thinking on-demand has no per-request cost or is always cheaper
- Assuming provisioned mode auto-scales without configuring auto scaling
- Believing you can switch modes unlimited times per day
- Confusing capacity units with storage cost
- Ignoring throttling risk from under-provisioning
Best Answer (HR Friendly)
“DynamoDB capacity is basically how much reading and writing your database can handle. You either reserve a fixed amount up front to save money on steady traffic (provisioned), or let AWS scale automatically and pay per request when traffic is unpredictable (on-demand).”
Code Example
import { DynamoDBClient, CreateTableCommand } from '@aws-sdk/client-dynamodb'
const client = new DynamoDBClient({ region: 'us-east-1' })
// Provisioned: reserve fixed RCUs/WCUs
await client.send(new CreateTableCommand({
TableName: 'OrdersProvisioned',
KeySchema: [{ AttributeName: 'orderId', KeyType: 'HASH' }],
AttributeDefinitions: [{ AttributeName: 'orderId', AttributeType: 'S' }],
BillingMode: 'PROVISIONED',
ProvisionedThroughput: { ReadCapacityUnits: 25, WriteCapacityUnits: 10 },
}))
// On-demand: no capacity to set, pay per request
await client.send(new CreateTableCommand({
TableName: 'OrdersOnDemand',
KeySchema: [{ AttributeName: 'orderId', KeyType: 'HASH' }],
AttributeDefinitions: [{ AttributeName: 'orderId', AttributeType: 'S' }],
BillingMode: 'PAY_PER_REQUEST',
}))Follow-up Questions
- How exactly are RCUs and WCUs calculated for a request?
- When would you move a table from on-demand to provisioned?
- How does DynamoDB auto scaling adjust provisioned capacity?
- What is burst capacity and how does it help avoid throttling?
- How do reserved capacity purchases lower provisioned cost?
MCQ Practice
1. Which billing mode charges you per request with no capacity to configure?
On-demand mode (PAY_PER_REQUEST) requires no RCU/WCU configuration and bills per read and write request.
2. How often can you switch a DynamoDB table between provisioned and on-demand?
DynamoDB allows switching a table's capacity mode at most once every 24 hours.
3. Which mode is generally cheapest for steady, predictable traffic?
Provisioned mode reserves capacity at a lower unit rate, making it cheaper for steady, forecastable workloads.
Flash Cards
What is provisioned capacity? — A mode where you reserve fixed RCUs and WCUs up front, paid whether used or not — cheapest for steady traffic.
What is on-demand capacity? — A mode with no capacity to set that auto-scales and bills per request — ideal for unpredictable or spiky workloads.
How often can you switch modes? — At most once every 24 hours per table.
Does provisioned mode scale automatically? — Only if you enable DynamoDB auto scaling; otherwise capacity stays fixed and can throttle under load.