DynoTable

Internals

Your table throttles while CloudWatch shows average utilization under 50%, and adaptive capacity sounds like a fix until one partition key still absorbs a disproportionate share of traffic.

Without a mental model of physical partitions, those behaviors look random.

This section is the deep end: how partition keys hash to partitions, how a request router finds your data, how GSIs are partitioned separately, and how far today's DynamoDB has moved from the original Dynamo paper.

Read it after modeling and indexing click; it explains the rules the earlier sections handed you.

What this section teaches you to do

  • Predict hot-key symptoms from hash distribution and item collection size.
  • Explain why a GSI lags the base table and why you cannot strong-read your own GSI write.
  • Describe adaptive capacity as redistribution, not unlimited burst on one key.
  • Connect partition splits and storage layout to why a Query reads one item collection in sort-key order.

Reading order

  1. How partition keys work: hash key to partition assignment; the unit of throughput isolation.
  2. Physical partitions: per-partition limits, splits, and the 10 GB LSI collection cap in context.
  3. Adaptive capacity: borrowing capacity across partitions; limits under sustained skew.
  4. Storage internals: the B-tree that keeps a partition's items in key order, and leader-based replication across three AZs.
  5. Request routing: the router fleet, the partition-map lookup, leader vs replica reads, and where throttling happens.
  6. GSI internals: separate partitions, asynchronous propagation, storage overhead per index item.
  7. From Dynamo paper to DynamoDB: historical lineage; what the 2007 design did and what replaced it.
0 of 8 readQuiz
How DynamoDB Partition Keys Work
How DynamoDB partition keys work. The hash that maps a key to a physical partition, why your key choice decides throughput, and how to avoid hot partitions.
Intermediate8 min read
DynamoDB physical partitions
DynamoDB physical partitions: the 10 GB, 3,000 read and 1,000 write unit ceilings, how partitions split, and why a hot key throttles with capacity to spare.
Advanced8 min read
DynamoDB Adaptive Capacity: What It Does and What It Cannot
DynamoDB burst and adaptive capacity, how they absorb spikes and boost a hot partition automatically, and the per-item ceiling neither of them can raise.
Advanced6 min read
How DynamoDB storage internals work
How DynamoDB stores data. Partition-key hashing, the B-tree that keeps a partition's items in key order, and leader-based quorum replication across three AZs.
Advanced8 min read
How DynamoDB Request Routing Works
How DynamoDB request routing works: a router fleet authenticates each request, hashes the key and sends it to a replica of the owning partition.
Advanced7 min read
How a DynamoDB GSI Is Stored Internally
How a DynamoDB GSI is stored. Its own partitions, asynchronous updates from the base table, projected attributes only, and capacity separate from the table.
Advanced9 min read
From the Dynamo Paper to DynamoDB
The 2007 Dynamo paper versus DynamoDB. What the ring, sloppy quorums and vector clocks did, and what the 2022 DynamoDB paper says replaced them.
Advanced7 min read
Knowledge checkTake the quiz
Check what you’ve learned in this section.

All items that share a partition key value form one item collection. It sits on one partition until DynamoDB splits it across several (an LSI prevents that).

Write 10,000 events per second to PK = TENANT#acme and you concentrate write units on a handful of physical partitions, even if the table has thousands.

Adaptive capacity can shift surplus from quiet partitions, and a busy key's collection can split by sort key, but one hot item, or a key written in sort-key order, still throttles at the partition ceiling. The way out is a higher-cardinality key, or a write-sharding suffix on the key that must stay hot; hot partitions covers both.

GSI propagation is asynchronous, typically within a fraction of a second under normal conditions per AWS, with no ConsistentRead escape hatch on the index.

Practice in the workbench

Download DynoTable and open Settings on a table you know is skewed to compare its key structure and indexes. Then run a Query on a heavy tenant's partition key and on a quiet one, and compare the item counts per key.

In the SQL Workbench, GROUP BY the partition key over a bounded Scan or Query result to see which keys carry the most items on screen.

That aggregation runs client-side on fetched rows; it does not scan the table for free.

The item size calculator helps explain why large item collections approach split thresholds. Item counts show storage skew, not traffic, and DynoTable does not expose CloudWatch metrics or partition heat maps.

For traffic, turn on CloudWatch Contributor Insights on the table or GSI (most-accessed and most-throttled keys) and watch the ReadKeyRangeThroughputThrottleEvents and WriteKeyRangeThroughputThrottleEvents metrics.

Read internals after Indexes so GSI write amplification and eventual consistency are already familiar.