On-Demand vs Provisioned Capacity in DynamoDB: Key Differences and Usage

In DynamoDB, on-demand capacity automatically adjusts to your application's traffic, charging you per request without needing capacity planning. Provisioned capacity requires you to specify read and write capacity units upfront, which can save costs if your traffic is predictable.

Quick Comparison

Here is a quick side-by-side comparison of on-demand and provisioned capacity modes in DynamoDB.

Factor	On-Demand Capacity	Provisioned Capacity
Billing Model	Pay per request	Pay for pre-allocated capacity units
Traffic Handling	Automatically scales with traffic	Fixed capacity, manual scaling needed
Cost Efficiency	Best for unpredictable or spiky workloads	Best for steady, predictable workloads
Setup Complexity	No capacity planning required	Requires estimating capacity needs
Throttling Risk	Low risk due to auto scaling	Higher risk if capacity is underestimated
Use Case Example	New apps or variable traffic	Mature apps with steady traffic

Key Differences

On-demand capacity mode in DynamoDB lets you pay only for the read and write requests your application actually makes. It automatically adjusts capacity to handle sudden increases or decreases in traffic without manual intervention. This makes it ideal for new applications or workloads with unpredictable traffic patterns.

In contrast, provisioned capacity requires you to specify how many read and write capacity units your table needs ahead of time. You pay for this capacity whether you use it or not. This mode is cost-effective when your workload is steady and predictable because you can optimize capacity to match your needs and avoid overpaying.

Another important difference is throttling. With provisioned capacity, if your application exceeds the allocated capacity, requests can be throttled and rejected. On-demand capacity reduces this risk by automatically scaling to meet demand, but it may cost more if traffic is consistently high.

Code Comparison

Here is how you create a DynamoDB table with provisioned capacity using AWS SDK for JavaScript (v3):

javascript

import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({ region: "us-east-1" });

const params = {
  TableName: "MyTable",
  KeySchema: [
    { AttributeName: "id", KeyType: "HASH" }
  ],
  AttributeDefinitions: [
    { AttributeName: "id", AttributeType: "S" }
  ],
  ProvisionedThroughput: {
    ReadCapacityUnits: 5,
    WriteCapacityUnits: 5
  }
};

const run = async () => {
  try {
    const data = await client.send(new CreateTableCommand(params));
    console.log("Table created:", data.TableDescription.TableName);
  } catch (err) {
    console.error(err);
  }
};

run();

Output

Table created: MyTable

On-Demand Equivalent

Here is how you create the same DynamoDB table with on-demand capacity mode using AWS SDK for JavaScript (v3):

javascript

import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({ region: "us-east-1" });

const params = {
  TableName: "MyTable",
  KeySchema: [
    { AttributeName: "id", KeyType: "HASH" }
  ],
  AttributeDefinitions: [
    { AttributeName: "id", AttributeType: "S" }
  ],
  BillingMode: "PAY_PER_REQUEST"
};

const run = async () => {
  try {
    const data = await client.send(new CreateTableCommand(params));
    console.log("Table created with on-demand capacity:", data.TableDescription.TableName);
  } catch (err) {
    console.error(err);
  }
};

run();

Output

Table created with on-demand capacity: MyTable

When to Use Which

Choose on-demand capacity when your application's traffic is unpredictable, spiky, or you want to avoid managing capacity settings. It is perfect for new projects or apps with variable workloads.

Choose provisioned capacity when you have a steady, predictable workload and want to optimize costs by pre-allocating capacity. This is ideal for mature applications with consistent traffic patterns.

Remember, on-demand offers ease and flexibility, while provisioned offers cost control and predictability.

Key Takeaways

On-demand capacity charges per request and auto-scales with traffic, requiring no capacity planning.

Provisioned capacity requires setting read/write units upfront and suits predictable workloads.

On-demand reduces throttling risk but may cost more with steady high traffic.

Provisioned capacity can save money if you accurately estimate your workload.

Use on-demand for new or variable apps; use provisioned for stable, mature apps.