DynamoDB ThrottlingException

TL;DR — Your request rate exceeded a limit. It's retryable — back off and retry (the SDK does this by default). If it persists, you're calling a control-plane API (CreateTable, UpdateTable, DescribeTable) too often, or hitting an account-level limit.

What it means

ThrottlingException: Rate of requests exceeds the allowed throughput.

ThrottlingException (and the related RequestLimitExceeded) signals a rate limit that isn't a provisioned table's own RCU/WCU setting. It comes back as HTTP 400 and is retryable. It's most common on control-plane operations performed too rapidly, and — for on-demand tables — it can be returned for any data-plane operation when the request rate is too high (including when you exceed a configured maximum on-demand throughput). The error carries ThrottlingReason fields naming the throttled resource and the limit that was hit.

Why it happens

  • Polling control-plane APIs — calling DescribeTable, ListTables, UpdateTable in a tight loop (e.g. waiting for a table to become ACTIVE).
  • Creating/deleting many tables quickly — concurrent control-plane operations are capped (no more than 500 tables/indexes in CREATING/UPDATING/DELETING at once).
  • A configured on-demand maximum throughput — exceeding MaxReadRequestUnits/MaxWriteRequestUnits on an on-demand table or GSI returns ThrottlingException.
  • A sudden burst on an on-demand table — new tables start at 4,000 writes/s and 12,000 reads/s, and exceeding double your previous peak within 30 minutes can throttle until DynamoDB scales.

How to fix it

  1. Retry with exponential backoff + jitter — the AWS SDKs do this automatically; keep retries enabled and consider adaptive retry mode.
  2. Stop tight-polling control-plane APIs. Use waiters (waitUntilTableExists) which poll on a sensible schedule instead of a hot loop.
  3. Batch and pace data-plane writes. Ramp bulk loads gradually so on-demand capacity can scale with you.
  4. Spread table operations over time rather than creating dozens at once.
  5. Check ThrottlingReason in the response. It names the throttled resource and limit — control-plane vs on-demand data-plane throttles need different fixes.

Example

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';
import {waitUntilTableExists} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({});
//  a waiter polls on a backoff schedule — not a tight DescribeTable loop
await waitUntilTableExists({client, maxWaitTime: 120}, {TableName: 'Orders'});

FAQ

Is ThrottlingException the same as ProvisionedThroughputExceededException? No. ProvisionedThroughputExceededException is the data-plane error for exceeding a table's provisioned capacity. ThrottlingException is most common on control-plane operations (CreateTable, UpdateTable, DescribeTable), which have low account-wide limits, and on very high-volume bursts.

How do I fix a DynamoDB ThrottlingException? Retry with exponential backoff and jitter — the AWS SDKs do this automatically. Stop tight-polling control-plane APIs (use waiters like waitUntilTableExists), ramp bulk loads gradually so on-demand capacity can scale with you, and spread table operations over time.

Check size in DynoTable

When control-plane throttling blocks table setup, use DynoTable to browse existing tables instead of polling DescribeTable in a loop — open tables with ⌘K after a single refresh. For bulk loads that trigger on-demand throttling, size the traffic with the pricing calculator before you ramp.

Switch profiles with ⌘P; Test Connection on Settings → Profiles confirms the account. See Connect to AWS and Install.

Sources

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.

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