Amazon DynamoDB

Definition

Amazon DynamoDB is a fully managed, serverless NoSQL database offering single-digit millisecond reads and writes at virtually unlimited scale. Data lives in tables of items (attribute maps) keyed by a required partition key (and optional sort key). Schema is schemaless per item, but access patterns are not — every query must hit the primary key or a GSI/LSI you designed upfront. Capacity modes are on-demand (pay per request, instant scale) or provisioned with auto scaling and reserved capacity for steady workloads.

DynamoDB Streams emit item-level change records for Lambda-driven event architectures. Global Tables provide multi-region, multi-active replication with last-writer-wins conflict handling. DynamoDB zero-ETL integrations to Amazon Redshift (2024+) replicate table changes into Redshift for analytics without custom CDC pipelines — pair operational DynamoDB with warehouse reporting without duplicating business logic in Glue jobs.

When to use it

• Known access patterns (get by user ID, query orders by user + time range) at high throughput without manual sharding.
• Serverless stacks (API Gateway + Lambda + DynamoDB) needing millisecond latency and horizontal scale by default.
• Session stores, gaming state, IoT telemetry, shopping carts, and idempotency token tables.
• Global Tables when each region must serve local writes with acceptable eventual consistency semantics.

When not to use it

• Ad hoc SQL reporting, multi-table joins, or ORM-centric CRUD without access-pattern discipline.
• Workloads requiring strong cross-item transactions across many partitions frequently — transactions exist but have limits.
• Large blob storage inside items — 400 KB item limit; store payloads in S3 and keep pointers in DynamoDB.

Tips

• Start design workshops with access patterns on paper (read/write paths, cardinality, hot keys) before creating the first table.
• Use on-demand for spiky or unknown traffic; switch to provisioned + auto scaling + reservations once daily RCU/WCU stabilize — savings are substantial at steady state.
• Enable PITR (35-day window) on production tables — on-demand backups alone miss granular restore-to-time scenarios.
• Watch hot partitions via CloudWatch ConsumedReadCapacityUnits per key metrics and Contributor Insights — celebrity users or sequential IDs cause throttling.
• Leverage zero-ETL to Redshift for analytics instead of scanning tables from Lambda cron jobs.

Gotchas

• Serious: Adding a new query pattern late often requires new GSIs or table redesign — migrations are doable but painful under live traffic.
• Serious: Hot partition keys (status=ACTIVE, shard=0) throttle the whole table despite high total capacity — design key cardinality deliberately.
• Regular: On-demand mode during sustained high QPS costs more than well-tuned provisioned — revisit mode quarterly.
• Regular: Global Tables conflicts resolve last-writer-wins — business logic must tolerate or prevent concurrent updates to the same item across regions.
• Regular: DynamoDB Streams trim after 24 hours — consumers lagging more than a day lose data permanently.

Official references

• DynamoDB zero-ETL integrations — Redshift replication setup.
• Best practices for designing tables — keys, GSIs, and hot partitions.

Related FactualMinds content

• Amazon RDS — when SQL fits better
• Amazon Redshift — zero-ETL analytics target
• AWS Serverless Services
• AWS Migration Services
• Cloud Cost Optimization