DynamoDB capacity modes (on-demand, provisioned) in AWS - Deep Dive

Overview - DynamoDB capacity modes (on-demand, provisioned)

What is it?

DynamoDB capacity modes determine how you pay for and manage the read and write throughput of your database. There are two main modes: on-demand and provisioned. On-demand mode automatically adjusts capacity based on your application's traffic, while provisioned mode requires you to specify the capacity in advance. These modes help balance cost and performance for different usage patterns.

Why it matters

Without capacity modes, you would either pay for too much unused database power or face slow responses when demand spikes. Capacity modes solve this by matching your database's power to your needs, saving money and keeping your app fast. This is crucial for apps that grow or have unpredictable traffic.

Where it fits

Before learning capacity modes, you should understand basic DynamoDB concepts like tables, items, and throughput. After mastering capacity modes, you can explore auto scaling, global tables, and cost optimization strategies.

Mental Model

Core Idea

DynamoDB capacity modes control how you pay for and manage database speed by choosing between automatic scaling or fixed capacity.

Think of it like...

It's like choosing between a taxi that charges you per ride without booking (on-demand) versus renting a car with a fixed monthly mileage limit (provisioned).

┌───────────────────────────────┐
│       DynamoDB Capacity Modes  │
├───────────────┬───────────────┤
│ On-Demand     │ Provisioned   │
├───────────────┼───────────────┤
│ Auto scales   │ Fixed capacity│
│ Pay per use   │ Pay for set   │
│ Good for      │ Good for      │
│ unpredictable │ steady load   │
│ traffic       │               │
└───────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

What is DynamoDB throughput

Concept: Introduce the idea of read and write capacity units as the measure of database speed.

DynamoDB measures how fast it can read or write data using capacity units. One read capacity unit lets you read up to 4 KB per second, and one write capacity unit lets you write up to 1 KB per second. These units define how much work your database can do at once.

Result

You understand that throughput is the speed limit for your database operations.

Knowing throughput units helps you grasp why capacity modes matter: they control how many units you get and pay for.

2

Foundation

Introduction to capacity modes

Concept: Explain the two capacity modes: on-demand and provisioned.

DynamoDB offers two ways to handle throughput: provisioned mode, where you set fixed capacity units ahead of time, and on-demand mode, where DynamoDB automatically adjusts capacity as needed. You pick one mode per table.

Result

You can identify the two capacity modes and their basic differences.

Understanding capacity modes is key to balancing cost and performance for your database.

3

Intermediate

How on-demand mode works

🤔Before reading on: do you think on-demand mode charges a fixed monthly fee or charges based on actual usage? Commit to your answer.

Concept: On-demand mode charges you only for the reads and writes your app actually uses, without pre-planning capacity.

In on-demand mode, DynamoDB instantly adapts to your app's traffic. If your app suddenly needs more reads or writes, DynamoDB scales up automatically. You pay per request, so costs match your usage exactly. This mode is great for unpredictable or new apps.

Result

Your database handles sudden traffic spikes smoothly without manual changes.

Knowing on-demand mode removes the need to guess capacity, reducing risk of overpaying or throttling.

4

Intermediate

How provisioned mode works

🤔Before reading on: do you think provisioned mode requires you to guess your app's traffic or can it adjust instantly? Commit to your answer.

Concept: Provisioned mode requires you to set fixed read and write capacity units before use, which can be adjusted manually or with auto scaling.

In provisioned mode, you decide how many capacity units your table has. If your app needs more capacity later, you must increase it yourself or set up auto scaling. You pay for the capacity you reserve, even if you don't use it all. This mode suits apps with steady or predictable traffic.

Result

You control capacity and costs but must plan ahead to avoid slowdowns.

Understanding provisioned mode teaches you the tradeoff between cost control and flexibility.

5

Intermediate

Comparing cost and performance tradeoffs

🤔Before reading on: which mode do you think is cheaper for steady traffic, on-demand or provisioned? Commit to your answer.

Concept: Each mode has cost and performance strengths depending on traffic patterns.

On-demand mode is usually more expensive for steady, predictable traffic because you pay per request. Provisioned mode can be cheaper if you reserve just enough capacity. But if traffic spikes unexpectedly, provisioned mode can cause throttling unless you scale quickly. On-demand mode avoids throttling by scaling automatically.

Result

You can choose the best mode based on your app's traffic and budget.

Knowing these tradeoffs helps you optimize both cost and user experience.

6

Advanced

Using auto scaling with provisioned mode

🤔Before reading on: do you think auto scaling in provisioned mode reacts instantly to traffic spikes or with some delay? Commit to your answer.

Concept: Auto scaling adjusts provisioned capacity automatically but with some delay and limits.

Auto scaling watches your table's usage and adjusts capacity up or down within set limits. It helps avoid manual changes but reacts slower than on-demand mode. Sudden spikes can still cause throttling before scaling catches up. You set minimum and maximum capacity to control costs.

Result

Provisioned mode becomes more flexible but still requires planning.

Understanding auto scaling's limits prevents surprises during traffic spikes.

7

Expert

Hidden limits and burst capacity behavior

🤔Before reading on: do you think DynamoDB can handle unlimited sudden traffic bursts in on-demand mode? Commit to your answer.

Concept: Both modes have internal limits and burst capacity that affect performance during sudden traffic spikes.

DynamoDB allows short bursts above provisioned capacity using burst credits, but these are limited. On-demand mode can handle large spikes but has soft limits that can throttle very sudden huge traffic. Understanding these limits helps design apps that avoid unexpected slowdowns or errors.

Result

You can architect your app to handle traffic bursts gracefully.

Knowing internal limits helps avoid costly downtime and guides capacity planning.

Under the Hood

DynamoDB capacity modes control how throughput capacity is allocated and billed. Provisioned mode reserves fixed read/write units, which are distributed across partitions. On-demand mode uses a shared pool of capacity that dynamically allocates resources per request. Both modes use burst credits to handle short traffic spikes. Internally, DynamoDB partitions data and capacity to balance load and maintain performance.

Why designed this way?

Provisioned mode was the original design, giving users control and predictable costs. On-demand mode was added later to simplify scaling and reduce management overhead for unpredictable workloads. The design balances cost efficiency, performance, and ease of use, addressing different customer needs.

┌───────────────┐       ┌───────────────┐
│ Provisioned   │       │ On-Demand     │
│ Capacity      │       │ Capacity Pool │
│ (Fixed units) │       │ (Shared units)│
└──────┬────────┘       └──────┬────────┘
       │                       │
       │ Allocated to          │ Dynamically assigned
       │ partitions            │ per request
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ Partitions    │       │ Partitions    │
│ (Data shards) │       │ (Data shards) │
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does on-demand mode guarantee unlimited instant scaling without any throttling? Commit to yes or no.

Common Belief: On-demand mode can instantly handle any amount of traffic without throttling.

Reality: On-demand mode scales quickly but has soft limits and can throttle very sudden, extremely high traffic spikes.

Why it matters: Believing this can lead to unexpected app failures during traffic surges if capacity limits are exceeded.

Quick: In provisioned mode, if you set capacity too low, will DynamoDB automatically increase it to prevent throttling? Commit to yes or no.

Common Belief: Provisioned mode automatically adjusts capacity to prevent throttling even if you set it too low.

Reality: Provisioned mode requires manual or auto scaling configuration; otherwise, low capacity causes throttling.

Why it matters: Assuming automatic adjustment leads to performance issues and downtime under load.

Quick: Does on-demand mode always cost more than provisioned mode? Commit to yes or no.

Common Belief: On-demand mode is always more expensive than provisioned mode.

Reality: On-demand mode can be cheaper for unpredictable or low traffic, while provisioned mode is cheaper for steady high traffic.

Why it matters: Misjudging costs can cause overspending or poor performance.

Quick: Can you switch capacity modes on a DynamoDB table anytime without data loss? Commit to yes or no.

Common Belief: You can switch between on-demand and provisioned modes instantly without any impact.

Reality: Switching modes is possible but takes time and may affect availability during the change.

Why it matters: Ignoring this can cause unexpected downtime or errors during mode changes.

Expert Zone

1

Provisioned mode's capacity is split across partitions, so uneven data distribution can cause hot partitions and throttling despite sufficient total capacity.

2

On-demand mode uses internal adaptive algorithms that may delay scaling for very sudden spikes, so some throttling can occur before scaling catches up.

3

Auto scaling in provisioned mode has cooldown periods and scaling limits that require careful tuning to balance cost and performance.

When NOT to use

Avoid on-demand mode for consistently high and predictable workloads where provisioned mode with auto scaling is more cost-effective. Avoid provisioned mode for new or unpredictable apps without traffic estimates. For extremely high throughput needs, consider sharding data or using other AWS services like DynamoDB Accelerator (DAX) or caching layers.

Production Patterns

Many production systems start with on-demand mode during development and early launch to avoid capacity guessing, then switch to provisioned mode with auto scaling as traffic stabilizes. Hot partition mitigation by designing keys for even distribution is critical in provisioned mode. Combining on-demand mode with AWS Lambda triggers enables event-driven scaling architectures.

Connections

Auto Scaling

Builds-on

Understanding capacity modes helps grasp how auto scaling adjusts provisioned capacity to match traffic patterns.

Cloud Cost Optimization

Supports

Choosing the right capacity mode directly impacts cloud costs, making this knowledge essential for cost-effective cloud management.

Traffic Engineering (Networking)

Analogous pattern

Capacity modes in DynamoDB resemble traffic engineering in networks, where resources are allocated either statically or dynamically to handle varying loads efficiently.

Common Pitfalls

#1 Setting provisioned capacity too low without auto scaling.

Wrong approach:

CreateTable --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

Correct approach:

CreateTable --provisioned-throughput ReadCapacityUnits=50,WriteCapacityUnits=50
ConfigureAutoScaling --min-capacity 10 --max-capacity 100

Root cause:

Misunderstanding that provisioned mode requires capacity planning and scaling to avoid throttling.

#2 Assuming on-demand mode is always cheaper and using it for steady high traffic.

Wrong approach:

CreateTable --billing-mode PAY_PER_REQUEST
// No cost monitoring or switching to provisioned mode

Correct approach:

Start with on-demand mode for unpredictable traffic
Monitor costs
Switch to provisioned mode with auto scaling for steady high traffic

Root cause:

Not analyzing traffic patterns and cost implications before choosing capacity mode.

#3 Switching capacity modes during peak traffic without planning.

Wrong approach:

UpdateTable --billing-mode PROVISIONED
// During heavy traffic hours

Correct approach:

Schedule capacity mode changes during low traffic periods
Monitor table status
Confirm successful switch before peak hours

Root cause:

Ignoring the time and impact of capacity mode changes on availability.

Key Takeaways

DynamoDB capacity modes let you choose between automatic scaling with pay-per-use (on-demand) and fixed capacity with manual or auto scaling (provisioned).

On-demand mode is best for unpredictable or low traffic, while provisioned mode suits steady, predictable workloads for cost savings.

Provisioned mode requires careful capacity planning and may need auto scaling to handle traffic changes without throttling.

Both modes have internal limits and burst capacity that affect how they handle sudden traffic spikes.

Choosing the right capacity mode and understanding its behavior is essential for balancing cost, performance, and reliability in DynamoDB.