DynamoDB is AWS's managed key-value/document store. Sub-10ms latency at any scale, fully serverless, pay per request. The catch: you must design your schema for your queries upfront — no joins, no flexible querying. Get this right and it's magical; get it wrong and you re-architect.
Pricing model matters
On-demand: pay per request ($1.25 / million writes, $0.25 / million reads). Provisioned: pay per RCU/WCU/sec. On-demand is simpler and right for variable traffic. Provisioned cheaper for predictable workloads >50% utilized. Both have per-GB storage cost.
Single-table design
Counterintuitively, idiomatic DynamoDB uses ONE table for everything (Users, Orders, Items). Partition keys disambiguate entity types. Why: avoid expensive multi-table joins (DynamoDB has no joins). Trade: schema is intimidating until you've done it twice.
Partition key strategy
Partition key = where the item lives. Sort key = order within partition. Design for access patterns: 'get all orders for user X' → PK=user#X, SK=order#timestamp. 'Get recent orders globally' → PK=ORDERS, SK=timestamp (hot partition risk!).
Global Secondary Indexes (GSI)
Want to query by a non-key attribute? Add a GSI with that attribute as its key. GSIs are eventually consistent (1-2 sec lag) and double the write cost. Use sparingly; design primary key first.
Where DynamoDB wins
Sub-10ms latency at planetary scale. Zero ops (no provisioning, patching, sharding). Burstable. Strong PK consistency. Cost per request stays flat as you scale. Where it loses: anything requiring ad-hoc analytics, complex queries, or fast iteration on schema.