DynoTable

DynamoDB on-demand throughput exceeded

TL;DR — Yes, on-demand tables can still throttle. The three causes: you set a max throughput (MaxReadRequestUnits/MaxWriteRequestUnits) and passed it; you drove more than double your previous traffic peak within 30 minutes; or you hit a table-level quota (default 40,000 read request units and 40,000 write request units per table). Raise or remove the max, ramp traffic gradually, and keep exponential-backoff retries.

What it means

ThrottlingException: Rate of requests exceeds the allowed throughput.

On-demand mode scales to accommodate traffic, but not instantly and not without ceilings. New on-demand tables sustain up to 4,000 writes and 12,000 reads per second immediately, and on-demand instantly accommodates up to double your previous traffic peak. Exceeding a configured maximum, out-running that doubling within 30 minutes, or crossing a quota all surface as throttling — ThrottlingException is HTTP 400 and retryable, and the error carries ThrottlingReason fields (e.g. IndexWriteMaxOnDemandThroughputExceeded) naming the resource and the limit that was hit.

Why it happens

  • A configured max throughput — you set MaxReadRequestUnits/MaxWriteRequestUnits and demand crossed it; DynamoDB returns a ThrottlingException (it's a cost-control ceiling you chose, applied best-effort).
  • Faster than 2x the previous peak — on-demand instantly accommodates up to double your previous peak, but throttling can occur if you exceed double that peak within 30 minutes.
  • Cold-start ramp — a brand-new table (or a bulk load right after creation) exceeds the initial baseline of 4,000 writes and 12,000 reads per second.
  • Table-level quota — the default per-table ceiling of 40,000 read request units and 40,000 write request units; account-level quota breaches surface as RequestLimitExceeded instead.
  • A hot partition — traffic concentrated on one partition key, which has its own per-partition limit regardless of table mode.

How to fix it

  1. Raise the configured maximum — increase MaxReadRequestUnits/MaxWriteRequestUnits via UpdateTable, or set the value to -1 to remove your custom ceiling (service quotas still apply).
  2. Pre-warm before a known spike — use DynamoDB's warm throughput setting, or space traffic growth over at least 30 minutes so on-demand's doubling keeps ahead of demand instead of chasing a step change.
  3. Keep exponential-backoff retries — the SDK retries throttles by default; use adaptive retry mode for bursty loads.
  4. Throttle bulk imports or use the S3 import feature instead of hammering a fresh table.
  5. Spread the key space so no single partition key becomes hot — a hot partition throttles even when the table has headroom.
  6. Request a quota increase if you legitimately need more than 40,000 read/write request units on a table.

Chasing which key is soaking up the requests? Browse and filter the table in the DynoTable desktop app to find the hot partition key before it caps your throughput.

FAQ

Can a DynamoDB on-demand table be throttled? Yes. On-demand tables throttle when you pass a configured maximum throughput, drive more than double your previous traffic peak before DynamoDB finishes scaling, cross the default per-table quota of 40,000 read and 40,000 write request units, or concentrate traffic on a hot partition key.

How do I raise the on-demand throughput limit? Increase MaxReadRequestUnits/MaxWriteRequestUnits via UpdateTable, or set the value to -1 to remove your custom ceiling — account quotas still apply. If you need more than the default 40,000 request units per table, request a quota increase.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Work with DynamoDB without the Console

A fast DynamoDB desktop client that runs the real SQL DynamoDB can’t — JOINs, GROUP BY, aggregates — with visual editing and an AI agent on your own Bedrock keys.

DownloadSee pricing

Free 30-day trial, no credit card — then the Free plan with no time limit.