DynoTable

DynamoDB RequestLimitExceeded

TL;DR — You exceeded an account/table-level request-rate quota, not a table's own provisioned capacity. On-demand tables default to 40,000 read request units and 40,000 write request units per second. Keep the SDK's backoff retries, raise the quota in Service Quotas if the traffic is real, and spread load so a single table/partition isn't the bottleneck.

What it means

RequestLimitExceeded: Throughput exceeds the current throughput limit for your
account. To request a limit increase, contact AWS Support.

RequestLimitExceeded is one of the three throttling exceptions DynamoDB returns on the data plane (alongside ProvisionedThroughputExceededException and ThrottlingException). It signals you've hit an account-level service quota — such as the per-table throughput quota for on-demand tables — rather than a per-table provisioned RCU/WCU ceiling. It returns HTTP 400 and is retryable — the SDKs back off and retry automatically. The error carries ThrottlingReason fields (e.g. TableWriteAccountLimitExceeded or IndexReadAccountLimitExceeded) plus the affected resource's ARN.

Why it happens

  • On-demand table default ceiling — each on-demand table (and each of its GSIs) has an adjustable default quota of 40,000 read request units and 40,000 write request units per second. Sustained consumption past that throttles with account-level ThrottlingReasons until the quota is raised.
  • The table can't scale further under the account quota — per the AWS docs, the rate of on-demand requests exceeds the allowed account throughput "and the table cannot be scaled further". These quotas are backstop safeguards, and they can be increased.
  • A newly on-demand table warming up — a fresh on-demand table (or one just switched to on-demand) instantly serves up to double its previous peak; a much larger spike beyond that can throttle before it scales.
  • A single hot table absorbing a traffic spike far above its recent peak.

How to fix it

  1. Keep exponential-backoff retries on — the SDK default handles transient spikes. Use adaptive retry mode for bursty workloads. Don't disable retries.
  2. Raise the quota — request an increase to the per-table on-demand throughput (or the account table-count/throughput quota) in Service Quotas if the traffic is legitimate and sustained.
  3. Pre-warm before a known spike — ramp traffic up rather than jumping straight to peak, so on-demand scaling keeps ahead of demand.
  4. Spread load — shard hot keys and distribute writes so one table/partition isn't carrying the whole spike (hot-partition patterns).
  5. Cache hot reads (DAX or an app cache) to shed read pressure below the ceiling.

FAQ

How is RequestLimitExceeded different from ProvisionedThroughputExceededException? ProvisionedThroughputExceededException means a provisioned-capacity table exceeded its own configured RCU/WCU. RequestLimitExceeded means you hit an account- or table-level request-rate quota — most often the on-demand default of 40,000 read and 40,000 write request units per second — regardless of a single table's per-table setting.

Is RequestLimitExceeded retryable? Yes. It's a throttling error and the AWS SDKs retry it automatically with exponential backoff. Persistent occurrences mean you need a quota increase or to spread load, not more retries.

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.