DynamoDB On-Demand: What It Is and When to Use It

Definition

Amazon DynamoDB On-Demand is a serverless, pay-per-request capacity mode for Amazon's fully managed NoSQL database service. It eliminates the need for manual capacity planning by automatically and instantly scaling read and write throughput to match application demand, making it ideal for applications with new, unpredictable, or spiky traffic patterns.

How It Works

DynamoDB On-Demand abstracts away the complexity of managing throughput. Instead of provisioning a specific number of Read Capacity Units (RCUs) and Write Capacity Units (WCUs), you simply create a table in On-Demand mode and pay for the actual read and write requests your application performs.

The scaling mechanism is designed to be instantaneous. When a request arrives, DynamoDB serves it as long as the traffic volume does not exceed double the table's previous peak throughput within a 30-minute window. For example, if your application's traffic has previously peaked at 10,000 requests per second, On-Demand mode can instantly accommodate a spike of up to 20,000 requests per second. Once that new level is sustained, it becomes the new peak, allowing for subsequent scaling to 40,000 requests per second.

For a brand-new table, DynamoDB provides a generous default capacity, allowing it to immediately serve up to 4,000 write requests and 12,000 read requests per second. This ensures that new applications can handle significant traffic from the moment they are launched without throttling. If an existing table is switched to On-Demand mode, it retains its previously provisioned capacity as its initial peak.

Key Features and Limits

• Billing Model: Pay-per-request for read and write operations. You are billed for what you use, with no charges for idle capacity.
• Automatic Scaling: Throughput scales automatically and instantly to accommodate traffic, up to double the previous peak.
• No Capacity Planning: Eliminates the need to forecast traffic, configure auto-scaling policies, or manage provisioned capacity.
• Mode Switching: You can switch a table from Provisioned to On-Demand mode up to four times in a rolling 24-hour period. You can switch from On-Demand back to Provisioned mode at any time.
• Performance: Delivers the same single-digit millisecond latency as Provisioned mode, regardless of scale.
• Default Throughput Quotas: By default, tables have an account-level quota of 40,000 WCUs and 40,000 RCUs, which can be increased via a service quota request.
• Partition Throughput Limits: Individual database partitions still have physical limits of 3,000 RCUs and 1,000 WCUs per second. Throttling can still occur with a "hot key" (a poorly designed partition key) even in On-Demand mode.
• Item Size Limit: The maximum size for a single item in DynamoDB remains 400 KB, regardless of the capacity mode.

Common Use Cases

1. New Applications: When launching a new application, traffic patterns are often unknown. On-Demand is the recommended default as it avoids both over-provisioning costs and under-provisioning performance issues.
2. Unpredictable and Spiky Workloads: Ideal for applications with irregular traffic, such as social media apps during viral events, e-commerce sites during flash sales, or ticketing platforms.
3. Development and Test Environments: In non-production environments, traffic is typically sporadic. On-Demand ensures you only pay for the requests made during active development and testing, reducing costs for idle resources.
4. Serverless Architectures: On-Demand mode pairs perfectly with other serverless services like AWS Lambda and Amazon API Gateway. This creates a fully event-driven architecture where both the compute and database layers scale automatically and you pay only for what you use.
5. Infrequently Accessed Tables: For tables that are read from or written to only occasionally, On-Demand is more cost-effective than maintaining even a minimum level of provisioned throughput.

Pricing Model

DynamoDB On-Demand pricing is based on the number of read and write requests your application performs against your tables.

• Write Request Units (WRUs): One WRU can perform one write for an item up to 1 KB in size. Items larger than 1 KB consume additional WRUs.
• Read Request Units (RRUs): One RRU can perform one strongly consistent read for an item up to 4 KB in size. An eventually consistent read consumes only 0.5 RRUs.
• Transactional Requests: Transactional read or write operations consume two times the number of request units as standard operations.

As of a significant price reduction in late 2024, on-demand pricing became more competitive, making it the recommended default for most workloads. In addition to request units, you are also billed for data storage, continuous backups (Point-in-Time Recovery), data transfer out of an AWS Region, and any enabled features like Global Tables or DynamoDB Accelerator (DAX). The AWS Free Tier for DynamoDB applies only to tables in Provisioned mode, though the 25 GB of free storage applies to all tables.

For detailed and current pricing, always consult the official AWS DynamoDB Pricing page.

Pros and Cons

Pros:

• Simplicity and Agility: No capacity management overhead allows developers to move faster.
• Massive, Automatic Scalability: Effortlessly handles huge traffic spikes without manual intervention or throttling (within scaling limits).
• Cost-Effective for Unpredictable Workloads: Pay-per-use model prevents paying for idle capacity, making it cheaper for spiky or low-traffic patterns.
• Eliminates Throttling Risk: Greatly reduces the risk of ThrottlingException errors caused by under-provisioning.

Cons:

• Higher Cost at Sustained Scale: For predictable, high-volume workloads, Provisioned Throughput with high utilization is significantly more cost-effective, potentially 5-7x cheaper.
• No Reserved Capacity Discounts: You cannot purchase Reserved Capacity for On-Demand tables to achieve the deepest discounts available with Provisioned mode.
• Potential for Uncontrolled Costs: A bug, denial-of-service attack, or unexpected usage pattern can lead to a very high bill if not monitored. Setting maximum throughput limits and billing alarms is a recommended best practice.
• Scaling Limitations: While generous, the "double the previous peak" scaling rule means that an extremely sudden traffic increase (e.g., from 1,000 to 50,000 requests per second) can still be throttled until the table's capacity catches up.

Comparison with Alternatives

• DynamoDB On-Demand vs. DynamoDB Provisioned Throughput: This is the primary choice within DynamoDB. Choose On-Demand for unpredictable, new, or spiky workloads where ease of use is paramount. Choose Provisioned Throughput for predictable, steady-state applications where you can maintain high utilization (e.g., above 40%) to achieve the lowest possible cost per request.

• DynamoDB On-Demand vs. Amazon Aurora Serverless: This compares a NoSQL and a SQL serverless database. Choose DynamoDB On-Demand for key-value or document data models that require single-digit millisecond latency at any scale, common in high-traffic web apps, gaming, and IoT. Choose Aurora Serverless when your application requires the relational model, complex queries with joins, and strong transactional consistency (ACID), but still benefits from automatic scaling based on workload.

Exam Relevance

DynamoDB On-Demand is a critical topic for several AWS certification exams, particularly those focused on development, architecture, and databases.

• Relevant Certifications: AWS Certified Developer - Associate (DVA), AWS Certified Solutions Architect - Associate (SAA) & Professional (SAP), and especially the AWS Certified Database - Specialty (DBS-C01).
• Key Knowledge Areas:
  • Scenario-Based Choices: Be prepared to choose between On-Demand and Provisioned modes based on a description of an application's traffic pattern, cost sensitivity, and operational requirements.
  • Cost Implications: Understand the pricing models of both modes and when one becomes more cost-effective than the other.
  • Scaling Behavior: Know the "double the previous peak" rule and the initial throughput capacity of a new On-Demand table.
  • Serverless Integration: Understand how On-Demand fits into a broader serverless application architecture.
  • Operational Details: Know the frequency with which you can switch between modes.

Frequently Asked Questions

Q: Can I switch from Provisioned to On-Demand mode?

A: Yes. You can switch a table's capacity mode from Provisioned to On-Demand up to four times within a rolling 24-hour window. The change is seamless and does not cause downtime. Switching from On-Demand back to Provisioned can be done at any time.

Q: When is Provisioned Throughput cheaper than On-Demand?

A: Provisioned Throughput becomes more cost-effective when your application's traffic is predictable and consistently high. If your table's utilization of its provisioned capacity is consistently above approximately 40%, it will generally be cheaper than the per-request pricing of On-Demand mode. For even greater savings on predictable workloads, you can purchase Reserved Capacity for provisioned tables.

Q: How does On-Demand handle sudden, massive traffic spikes?

A: On-Demand mode instantly accommodates traffic up to double the table's previously established peak throughput. If a traffic spike exceeds this level within a 30-minute window, requests may be throttled. However, as the higher traffic level is sustained, DynamoDB automatically sets this as the new peak, allowing it to serve double that new peak in the future.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.