SW BBANG

You built a DynamoDB table, shipped it to production, and now reads are throttling under load — even though your provisioned capacity looks fine on paper. Nine times out of ten, the culprit is a poorly chosen partition key that funnels all traffic into a single physical partition. Understanding how DynamoDB partition keys work internally is the difference between a table that scales effortlessly and one that becomes a production incident at 2am. TL;DR: DynamoDB Partition Key Performance at a Glance Concern Key Point What is a partition key? The attribute DynamoDB hashes to determine which physical storage node holds the item What is a hot partition? A single partition receiving disproportionate read/write traffic, exhausting its per-partition throughput ceiling Why low-cardinality keys fail All items with the same key value land on the same partition — traffic concentrates regardless of total table capacity ...

You've modeled your DynamoDB table around one access pattern, and now a new query requirement has emerged — one that doesn't fit your primary key. Secondary indexes are the solution, but choosing between a Local Secondary Index (LSI) and a Global Secondary Index (GSI) has architectural consequences that are difficult to reverse. TL;DR — Quick Comparison Dimension LSI (Local Secondary Index) GSI (Global Secondary Index) Partition Key Same as base table Any attribute (can differ from base table) Sort Key Different attribute (required) Any attribute (optional) Creation Time At table creation only Any time (added/deleted dynamically) Consistency Strongly consistent reads supported Eventually consistent reads only Storage Scope Shares partition storage wit...