How DynamoDB works

Finding one item among billions

Imagine a phone book with a billion names and you need one entry in about a millisecond. Flipping through is hopeless. DynamoDB never flips, it computes the page.

Every item you store has a partition key. DynamoDB runs it through a hash function, and the result points at exactly one storage location. No scan, a direct jump.

Partitions: where your data actually lives

That “one location” is a partition, a slice of your table on fast SSDs. A table is split across many partitions as it grows in size or throughput.

Each write is durably persisted across multiple Availability Zones (typically three) before it's acknowledged. Lose a whole data centre and your data is still there, you never configure this.

What actually triggers DynamoDB to split a partition?

Two things: storage (when a partition fills up it splits to make room) and throughput (if you provision more capacity than one partition's ceiling can serve, it splits to spread the load). Splits are managed for you, which is why capacity is divided per partition, the setup for the next section. (You may see an old “10 GB per partition” figure quoted; AWS no longer documents a fixed per-partition size.)

The hot-partition trap

Here's the counter-intuitive part: you can be throttled while most of your capacity sits idle. Each partition has its own ceiling, about 3,000 read units and 1,000 write units per second.

If your key sends most traffic to one partition (every ID starting with the same prefix, one celebrity user, a single “today” bucket), that partition hits its ceiling and starts throttling, no matter how much table-wide capacity you bought.

⚓ Bites people running gaming leaderboards, IoT fleets reporting on the same timestamp, and multi-tenant apps where one big customer dominates.

Eventually vs. strongly consistent reads

DynamoDB's default read is eventually consistent: cheap, fast, can come from any of the three copies, but might be a beat behind a very recent write.

A strongly consistent read always reflects the latest write, because it goes to the leader copy.

What you actually pay for

DynamoDB bills in capacity units. One WCU = one write of an item up to 1 KB/second. One RCU = one strongly-consistent read up to 4 KB/second (or two eventually-consistent reads). Bigger items round up into more units.

Two modes: on-demand auto-scales and you pay per request; provisioned means you set the capacity (cheaper at steady, predictable load, and it can auto-scale too).

Why does a 5 KB read cost 2 RCUs, not 1.25?

RCUs are charged in whole 4 KB blocks, rounded up. A 5 KB item spans two blocks (4 KB + 1 KB), so a strongly-consistent read costs 2 RCUs; an eventually-consistent read of the same item costs 1 RCU (half rate). Keeping items small directly cuts cost.

The mindset shift: design for queries, not data

In SQL you model your data, then query it any way later. DynamoDB flips this: you list your access patterns first, then design the table so each one is a direct key lookup. No joins means no after-the-fact slicing. (DynamoDB does offer PartiQL, a SQL-like syntax, but under the hood it's still key-based access, not relational SQL with joins.)

Need to look something up by an attribute that isn't your partition key? You add a Global Secondary Index (GSI), effectively a second copy of the table keyed differently, kept in sync for you.

⚓ This is why DynamoDB tables often look strange to SQL eyes, one table, overloaded keys , yet serve every query in a single fast hop.

GSI vs. LSI, what’s the difference?

A Local Secondary Index (LSI) shares the table's partition key but adds a different sort key, and must be created with the table. A Global Secondary Index (GSI) can use a completely different partition key, can be added anytime, and has its own capacity. GSIs are eventually consistent with the base table, and strongly-consistent reads aren't available on a GSI at all.