DynamoDB On-Demand Throughput: Measured

How much throughput does a new DynamoDB on-demand table get?

A brand-new On-demand capacity table serves about 4,130 writes per second — AWS documents 4,000 — and at least 12,700 eventually-consistent reads per second. We measured both on 2026-08-27 against a table created minutes earlier: writes pinned at 4,130 ±2/s across every over-baseline load we offered, and reads never throttled at all before our own load generator ran out of headroom.

Those two numbers, and everything else on this page, come from counting real requests against the live service — not from restating the documentation. The method, the raw data, and the three failed attempts are written up in the benchmark story; this page is the reference the numbers live on.

The write ceiling on a fresh table

Offered load ramped in 30-second windows against a table that had never seen traffic. Every request carried a ~1 KB item with a uniformly random key — no Hot partition involved:

The documented 4,000 write/s baseline holds, with about 3% of headroom above it. The ceiling is remarkably flat: 4,132, 4,131, 4,134 achieved per second at 5,000, 6,000 and 8,000 offered. Latency does not degrade as you cross it — p50 write latency stayed at 4–5 ms in-region in every window. The service does not slow down; it rejects.

What the throttle actually returns

The first rejection arrived 0.9–3.8 seconds into each over-baseline window (the higher the offered rate, the sooner it came). Verbatim:

ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

Two things to plan around. It is an HTTP 400, not a 5xx — a retry policy or alarm that only watches 5xx will miss on-demand throttling entirely (the SDKs do retry it by default; see Exponential backoff). And the hot-key hint is a default suggestion, not a diagnosis — our keys were uniformly random, so at small scale the first suspect for this message is the table-level ceiling, not your key schema. The four distinct throttling causes have their own guide.

The read ceiling

Reads ran against a second fresh table seeded with 1,000 items, as Eventually consistent read GetItems (~1 KB, 0.5 read units each):

Zero throttles at every rate. The documented 12,000 read/s baseline holds, and we could not find its actual edge: at 16,000/s offered, five of our eight runners saturated client-side, so 12,762/s is where our fleet topped out — not where DynamoDB did. Reads answered at 2–4 ms p50 in-region.

How the ceiling grows under sustained load

AWS documents that on-demand capacity grows to accommodate up to double the previous peak, and that exceeding double the previous peak within 30 minutes may throttle. We held 8,000 writes/s of offered load against one table for 34 contiguous minutes (four 8-minute waves with under a minute of pause between them) and watched the ceiling move, minute by minute:

Reading the timeline:

• The first ceiling is sticky. Through the entire first 8 minutes the table held at its ~4,000/s baseline — sustained over-demand did not move it within that window.
• Growth arrives in ~1,000/s steps, not a ramp. The ceiling stepped to ~5,000/s around minute 9, ~6,000/s around minute 26, and ~7,000/s a minute later, then held 7,000/s flat to the end. Each step lands abruptly between one minute and the next. Two of the three steps landed near our wave boundaries, so the sub-minute pauses may interact with the growth mechanism — we report the timing as observed.
• Half an hour of sustained demand did not double the ceiling. After 34 minutes at 8,000/s offered, the table served 7,000/s — 1.75× its starting ceiling, still short of both the offered rate and a clean doubling. Throttled requests fell wave over wave (1.9M → 0.5M) as capacity grew.

If your launch-day traffic will exceed ~4,000 writes/s on a new table, pre-warm it: either drive synthetic load ahead of the event, or set the table's maximum on-demand throughput explicitly and let AWS provision for it. The on-demand vs provisioned guide covers when each mode wins, and auto scaling is the provisioned-mode counterpart of what you watched happen automatically here.

Two numbers that surprised us

• Create-to-ACTIVE time varies 3×. A fresh on-demand table reached ACTIVE in 7.4 seconds on one run and 22 seconds on two others, same region, same schema. Budget for the slow case in any table-per-tenant or table-per-test design.
• The whole benchmark cost $0.97. 672,116 billed writes and 1.08 million reads. The 34-minute sustained-growth run cost $12.67 more. Measuring the service yourself is cheaper than one wrong capacity decision — and you can price a workload like this ahead of time with the DynamoDB pricing calculator.

Scope and method, honestly

Everything above is one table per phase, one day, one region (us-east-1), ~1 KB items, uniform random keys. Per-partition limits (3,000 read units / 1,000 write units per second) sit below the table-level behavior measured here and have their own failure modes. Account-level quotas and the hard service limits are on the DynamoDB limits reference, measured the same way. And if you work against DynamoDB daily, DynoTable is our desktop client for it — built by the same team, with the same habit of checking claims against the live service before repeating them.