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 before DynamoDB finished scaling; or you hit an account/table quota (default 40,000 RCU / 40,000 WCU per table). Raise or remove the max, ramp traffic gradually, and keep exponential-backoff retries.

What it means

ThrottlingException: Throughput exceeds the maximum OnDemandThroughput
configured on table or index

On-demand mode scales to accommodate traffic, but not instantly and not without ceilings. New on-demand tables serve up to ~4,000 write and ~12,000 read request units immediately, then double their capacity as sustained traffic grows. Exceeding a configured maximum, out-running that doubling, or crossing an account quota all surface as throttling.

Why it happens

  • A configured max throughput — you set MaxReadRequestUnits/MaxWriteRequestUnits and demand crossed it; you get ThrottlingException (message references OnDemandThroughput).
  • Faster than 2x the previous peak — on-demand roughly doubles capacity to meet demand, but a sudden spike beyond double the last 30-minute peak can throttle until it catches up.
  • Cold-start ramp — a brand-new table (or a bulk load right after creation) exceeds the initial 4,000-WCU/12,000-RCU baseline.
  • Account/table quota — the default per-table 40,000 RCU / 40,000 WCU ceiling, or an account-level quota.
  • 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 it to -1 to remove your custom ceiling (account quotas still apply).
  2. Pre-warm before a known spike — ramp traffic up gradually 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 RCU/WCU 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.

Trabalhe com o DynamoDB sem o Console

O DynoTable é um cliente desktop rápido para o DynamoDB — navegue pelas tabelas, execute consultas no estilo SQL e edite itens localmente.

BaixarVer preços