Table capacity modes (on-demand vs provisioned) in DynamoDB - Trade-offs & Expert Analysis

Overview - Table capacity modes (on-demand vs provisioned)

What is it?

Table capacity modes in DynamoDB determine how the database handles read and write throughput. There are two main modes: on-demand and provisioned. On-demand mode automatically adjusts capacity based on traffic, while provisioned mode requires you to specify capacity ahead of time. This choice affects cost, performance, and scalability.

Why it matters

Choosing the right capacity mode helps control costs and ensures your application runs smoothly. Without these modes, you might pay too much for unused capacity or face slowdowns during traffic spikes. Proper capacity management prevents wasted resources and keeps user experience consistent.

Where it fits

Before learning about capacity modes, you should understand basic DynamoDB concepts like tables, items, and throughput. After this, you can explore advanced topics like auto-scaling, cost optimization, and performance tuning.

Mental Model

Core Idea

Table capacity modes decide whether DynamoDB automatically adjusts throughput or requires manual capacity settings to balance cost and performance.

Think of it like...

It's like choosing between a taxi that waits and charges by the ride (on-demand) versus renting a car with a fixed monthly fee regardless of how much you drive (provisioned).

┌───────────────────────────────┐
│       Table Capacity Modes     │
├───────────────┬───────────────┤
│ On-Demand     │ Provisioned   │
├───────────────┼───────────────┤
│ Auto scales   │ Fixed capacity│
│ Pay per use   │ Pay fixed rate│
│ Handles spikes│ Needs planning│
└───────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding DynamoDB Throughput Basics

Concept: Learn what throughput means in DynamoDB and why it matters.

Throughput is how much data your table can read or write per second. DynamoDB measures this in Read Capacity Units (RCUs) and Write Capacity Units (WCUs). Each RCU lets you read up to 4 KB per second, and each WCU lets you write up to 1 KB per second. If your app tries to read or write more than your capacity, requests get throttled (slowed down).

Result

You understand that throughput limits how fast your app can access data and that exceeding it causes delays.

Knowing throughput basics helps you see why capacity modes exist: to manage these limits and avoid slowdowns.

2

Foundation

What Is Provisioned Capacity Mode?

Concept: Provisioned mode requires you to set fixed read and write capacity before use.

In provisioned mode, you decide how many RCUs and WCUs your table needs. You pay for this capacity whether you use it or not. If your app traffic grows, you must manually increase capacity or use auto-scaling. If traffic drops, you still pay for the set capacity.

Result

You know how to set fixed capacity and the cost implications of over- or under-provisioning.

Understanding provisioned mode shows the tradeoff between control and risk of paying for unused capacity.

3

Intermediate

How On-Demand Capacity Mode Works

Concept: On-demand mode automatically adjusts capacity based on traffic without manual settings.

On-demand mode lets DynamoDB handle all capacity scaling. You don't set RCUs or WCUs. Instead, you pay per request. This mode is great for unpredictable or spiky workloads because it instantly adapts. However, it can be more expensive for steady, high traffic.

Result

You see how on-demand mode simplifies capacity management and adapts to traffic changes.

Knowing on-demand mode helps you avoid manual capacity planning and handle sudden traffic spikes smoothly.

4

Intermediate

Comparing Costs Between Modes

🤔Before reading on: Do you think on-demand is always cheaper than provisioned? Commit to your answer.

Concept: Costs differ based on usage patterns between on-demand and provisioned modes.

Provisioned mode charges a fixed rate for capacity, so if your usage is steady and predictable, it can be cheaper. On-demand charges per request, so it’s better for unpredictable or low traffic. For very high steady traffic, provisioned with auto-scaling usually saves money. For bursty or unknown traffic, on-demand avoids overpaying.

Result

You understand cost tradeoffs and when each mode is financially better.

Understanding cost differences helps you pick the best mode for your app’s traffic pattern and budget.

5

Intermediate

When to Use Auto-Scaling with Provisioned Mode

🤔Before reading on: Do you think auto-scaling removes all manual capacity management? Commit to your answer.

Concept: Auto-scaling adjusts provisioned capacity automatically within set limits based on usage.

Auto-scaling watches your table’s traffic and increases or decreases capacity to match demand. You set minimum and maximum capacity limits. This reduces manual work but still requires planning limits. It helps avoid throttling and saves cost compared to fixed provisioned capacity.

Result

You see how auto-scaling blends manual control with automation in provisioned mode.

Knowing auto-scaling’s role clarifies how provisioned mode can be flexible and cost-effective.

6

Advanced

Limits and Throttling Behavior in Each Mode

🤔Before reading on: Do you think on-demand mode never throttles? Commit to your answer.

Concept: Both modes have limits and can throttle, but their behaviors differ.

Provisioned mode throttles when traffic exceeds set capacity. On-demand mode can handle sudden spikes but has soft limits that can throttle if traffic grows too fast or too large. AWS may temporarily throttle on-demand tables if usage exceeds internal limits, but it recovers quickly. Understanding these limits helps design resilient apps.

Result

You grasp that no mode guarantees zero throttling and that limits differ.

Knowing throttling nuances prevents surprises and helps design apps that handle capacity limits gracefully.

7

Expert

Choosing Capacity Modes for Global and Multi-Region Tables

🤔Before reading on: Do you think capacity mode choice affects global table replication? Commit to your answer.

Concept: Capacity modes impact how global tables handle replication and cost across regions.

Global tables replicate data across multiple regions for availability and latency. Each region’s table can have its own capacity mode. Using provisioned mode requires managing capacity per region, while on-demand mode simplifies this but can increase cost. Also, replication traffic counts toward capacity, so planning is critical. Experts balance cost, performance, and complexity when choosing modes for global tables.

Result

You understand how capacity modes affect multi-region setups and replication costs.

Knowing this helps design scalable global applications that optimize cost and performance.

Under the Hood

DynamoDB capacity modes control how the service allocates resources for read and write operations. Provisioned mode reserves fixed throughput capacity on backend servers, ensuring predictable performance but requiring manual adjustments. On-demand mode uses a serverless model that dynamically allocates resources per request, scaling instantly but with internal soft limits to protect system stability.

Why designed this way?

Provisioned mode was the original design to give users control and predictable billing. On-demand was introduced later to simplify scaling and handle unpredictable workloads without manual intervention. The tradeoff is between cost predictability and operational simplicity. AWS designed on-demand to protect backend stability with soft limits, balancing flexibility and reliability.

┌───────────────┐       ┌─────────────────────┐
│ Client App    │──────▶│ DynamoDB Frontend    │
└───────────────┘       └─────────┬───────────┘
                                   │
               ┌───────────────────┴───────────────────┐
               │                                       │
       ┌───────▼────────┐                     ┌────────▼────────┐
       │ Provisioned     │                     │ On-Demand       │
       │ Capacity Layer  │                     │ Capacity Layer  │
       │ (Fixed RCUs/WCUs)│                    │ (Dynamic scaling)│
       └─────────────────┘                     └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does on-demand mode guarantee zero throttling? Commit yes or no.

Common Belief: On-demand mode never throttles because it scales automatically.

Reality: On-demand mode can throttle if traffic spikes exceed internal soft limits or if usage grows too fast.

Why it matters: Believing on-demand never throttles can lead to unprepared apps that fail under extreme load.

Quick: Is provisioned mode always cheaper for high traffic? Commit yes or no.

Common Belief: Provisioned mode is always cheaper for high traffic workloads.

Reality: Provisioned mode is usually cheaper for steady high traffic, but on-demand can be more cost-effective if traffic is unpredictable or bursty.

Why it matters: Assuming provisioned is always cheaper may cause overspending or poor performance.

Quick: Can you switch capacity modes instantly without downtime? Commit yes or no.

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

Reality: Switching modes takes time and may cause temporary throttling or errors during transition.

Why it matters: Expecting instant switching can cause unexpected downtime or errors in production.

Quick: Does auto-scaling eliminate all manual capacity management? Commit yes or no.

Common Belief: Auto-scaling removes the need to plan capacity limits in provisioned mode.

Reality: Auto-scaling requires setting minimum and maximum capacity limits and monitoring to avoid throttling or overspending.

Why it matters: Ignoring limits can lead to throttling or unexpectedly high costs.

Expert Zone

1

Provisioned capacity mode allows fine-tuned control over throughput but requires careful monitoring to avoid throttling or wasted capacity.

2

On-demand mode's internal soft limits protect DynamoDB's stability but can cause throttling during very rapid traffic spikes, which is often overlooked.

3

Global tables can have mixed capacity modes per region, requiring complex cost and performance balancing strategies.

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 unpredictable or very spiky workloads where manual capacity planning is impractical. For extremely latency-sensitive applications, consider provisioned mode for guaranteed throughput.

Production Patterns

Many production systems start with on-demand mode during development or unpredictable traffic phases, then switch to provisioned with auto-scaling for cost savings at scale. Global applications often use provisioned mode in primary regions and on-demand in less critical regions to balance cost and availability.

Connections

Serverless Computing

On-demand capacity mode is a serverless model that abstracts resource management.

Understanding serverless principles helps grasp how on-demand mode automatically scales without manual intervention.

Cloud Cost Optimization

Capacity modes directly impact cloud spending and budgeting strategies.

Knowing capacity modes aids in designing cost-efficient cloud architectures and avoiding surprise bills.

Traffic Engineering in Networks

Managing capacity modes is similar to controlling bandwidth allocation and handling traffic bursts in networks.

Recognizing this connection helps apply traffic shaping and load balancing concepts to database throughput management.

Common Pitfalls

#1 Setting provisioned capacity too low causes throttling during traffic spikes.

Wrong approach:

CREATE TABLE MyTable (id STRING) WITH PROVISIONED_CAPACITY (read=5, write=5);

Correct approach:

CREATE TABLE MyTable (id STRING) WITH PROVISIONED_CAPACITY (read=50, write=50);

Root cause:

Underestimating traffic volume leads to insufficient capacity and request throttling.

#2 Switching capacity mode without planning causes temporary errors.

Wrong approach:

ALTER TABLE MyTable SET CAPACITY_MODE = 'ON_DEMAND'; -- done instantly without checks

Correct approach:

Plan switch during low traffic, monitor for throttling, and allow time for mode change to complete.

Root cause:

Ignoring transition time and impact causes unexpected downtime or throttling.

#3 Using on-demand mode for steady high traffic leads to high costs.

Wrong approach:

CREATE TABLE MyTable WITH ON_DEMAND_CAPACITY; -- for a table with constant heavy traffic

Correct approach:

CREATE TABLE MyTable WITH PROVISIONED_CAPACITY (read=1000, write=1000) AND AUTO_SCALING;

Root cause:

Not matching capacity mode to traffic pattern causes unnecessary expenses.

Key Takeaways

DynamoDB capacity modes control how throughput is managed and billed, balancing cost and performance.

Provisioned mode requires manual capacity settings and is best for predictable workloads with steady traffic.

On-demand mode automatically scales capacity and suits unpredictable or spiky workloads but can cost more for steady high traffic.

Auto-scaling in provisioned mode helps adjust capacity automatically within limits but still needs planning.

Understanding throttling limits and mode switching impacts is essential to avoid downtime and optimize costs.