Each DynamoDB partition serves up to 3,000 read units and 1,000 write units a second, whatever the table's capacity. One key with 20 KB items tops out at 1,200 eventually consistent reads or 50 writes a second. The limits by item size as a chart, how to spot a hot key, and write sharding when one key really is that busy.
Eventually consistent reads
Strongly consistent reads
Writes
Maximum requests per second against a single partition key. From the documented 3,000 read units and 1,000 write units per partition per second. Log scale.
On-demand mode and adaptive capacity spread load across partitions and isolate busy items, but they can't make one item's key exceed one partition's limit. A table can have plenty of capacity and still throttle one key: a celebrity's profile, a global counter, today's date as a partition key.
Throttled requests while consumed capacity for the table is well under its limit.
CloudWatch Contributor Insights for DynamoDB shows the most accessed and most throttled keys.
Keys that are a date, a status or a constant are the usual suspects.
Cache hot reads (DAX, ElastiCache, or a CDN for public data) so the key isn't read on every request.
Shard hot writes: append a suffix (COUNTER#0 to COUNTER#9) and sum the shards when reading.
Keep hot items small: a 1 KB item takes four times the writes of a 4 KB one on the same key.
Choose keys with many values: customer or order IDs, not dates or statuses.
We'll read your Contributor Insights and key design with you and point at the hot key. Free, 30 minutes.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
One Screen, 241 DynamoDB Requests: How Nested GraphQL Queries Fan Out on AppSync
A feed of 20 posts, each with its author and 10 comments with their authors, is one GraphQL query and 241 DynamoDB requests when each relationship resolver fetches per parent. The arithmetic by page size and nesting depth, what it costs per million screen views, and four ways to cut it, from batching to a single Postgres join.
Read
DynamoDB vs Postgres, Measured in AWS: 53 Workloads From the Same Client
We ran 53 workloads against RDS Postgres 17 and DynamoDB from one Fargate task in the same Availability Zone, at 100,000, 1 million and 5 million orders. Key lookups took 0.35 ms in Postgres and 2.7 ms in DynamoDB; a two-item transaction 1.75 ms against 20 ms; a question nobody designed for, 0.08–2.7 s against a full table scan. The full results, with the method and every caveat.
Read
As of November 4, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.