Amazon DynamoDB

AWS Cloud Engineering hub

DynamoDB is AWS's fully managed, serverless NoSQL database delivering single-digit-millisecond read and write latency at any scale, with no capacity planning required in On-Demand mode. Tables store schema-flexible items identified by a mandatory primary key, making it ideal for simple, high-throughput key-based access patterns rather than workloads needing SQL joins or complex ad-hoc queries.

A ride-hailing app stores active trip state in DynamoDB keyed by TripId, relying on single-digit-millisecond lookups to serve location updates to millions of concurrent riders, while using TTL to automatically expire trip records 24 hours after completion at zero extra cost.

Partition Key Design Is the Critical Decision

A poorly chosen partition key — like Status with only a few possible values — concentrates all traffic on one physical partition, creating a hot-partition bottleneck. High-cardinality keys like UserId or TripId spread load evenly.

Streams Enable Global Tables

DynamoDB Streams captures every item change as an ordered event log; Global Tables (active-active multi-region replication) require Streams to be enabled first, and typically replicate a write across regions in under one second.

Common Mistake
Using Scan in production — it reads every item in the table before filtering. On a 10-million-item table this is slow and expensive; design access patterns around Query and Global Secondary Indexes instead.

Frequently Asked Questions

Why would you pick DynamoDB over a relational database like RDS?

DynamoDB trades relational flexibility for guaranteed low latency at scale — reads and writes stay in the single-digit-millisecond range whether you have a thousand items or a billion, because there's no query planner doing joins or scans across unpredictable data volumes. It fits access patterns you can define upfront by key, like a shopping cart, session store, or leaderboard, not ad-hoc reporting queries.

What's the most common mistake engineers make when they first use DynamoDB?

Designing the table like a relational schema — normalizing data into multiple tables and expecting to join them at query time. DynamoDB has no joins, so the standard practice is single-table design: modeling access patterns first, then denormalizing data into one table with composite keys and secondary indexes to serve those patterns directly. Getting this wrong usually means expensive scans instead of cheap, indexed queries.