Amazon DynamoDB: What It Is and When to Use It

Definition

Amazon DynamoDB is a fully managed, serverless, distributed NoSQL key-value and document database that delivers single-digit millisecond latency at any scale. Launched in 2012, it powers many of the largest workloads on AWS (including Amazon.com's retail platform) and requires no server management, patching, or capacity planning — you create a table, define a primary key, and start reading and writing.

How It Works

At its core, DynamoDB is a hash-partitioned distributed database:

• Table — the top-level container, similar to a relational table but schemaless beyond the primary key.
• Item — a single record (up to 400 KB), made of attributes. Different items in the same table can have different attributes.
• Primary key — either a single partition key (simple primary key) or a composite partition key + sort key. DynamoDB hashes the partition key to route items to physical partitions.

DynamoDB automatically splits data across multiple partitions for horizontal scale, replicates each item across three AZs for durability, and exposes a 99.99% availability SLA (99.999% for Global Tables).

You interact with DynamoDB through the AWS SDK (PutItem, GetItem, Query, Scan, UpdateItem, DeleteItem, TransactWriteItems, TransactGetItems, and the higher-level BatchGetItem / BatchWriteItem). PartiQL provides a SQL-like dialect on top of the same primitives.

Key Features and Limits

Capacity modes

• On-Demand — pay per request. DynamoDB scales to any traffic instantly. Best for unpredictable workloads, dev/test, and scale-to-zero patterns.
• Provisioned — you specify Read Capacity Units (RCU) and Write Capacity Units (WCU) per second, optionally with Application Auto Scaling. Best for steady or predictable traffic; cheaper at scale.

Secondary indexes

• Global Secondary Index (GSI) — different partition key (and optional sort key) than the base table. Eventual consistency by default. Separate RCU/WCU in provisioned mode. Up to 20 GSIs per table.
• Local Secondary Index (LSI) — same partition key as the base table but a different sort key. Must be created at table creation. Shares the table's throughput. Up to 5 LSIs per table.

Data features

• Transactions — ACID across up to 100 items in the same or across tables.
• TTL — per-item expiration timestamps; items are deleted within 48 hours of expiry at no cost.
• DynamoDB Streams — change-data-capture for 24 hours after a write, ordered per partition. Feeds Lambda (via event source mappings) and Kinesis Data Streams (optional).
• Global Tables — multi-active, multi-Region replication with last-writer-wins conflict resolution. 99.999% availability SLA.
• Point-in-Time Recovery (PITR) — restore any second in the last 1–35 days.
• On-Demand backups — full snapshots retained until deleted, integrated with AWS Backup.

Performance features

• DynamoDB Accelerator (DAX) — in-cluster write-through cache for microsecond reads on cacheable hot items.
• Adaptive capacity — automatically rebalances throughput across partitions to absorb hot keys.
• Import/Export to S3 — bulk load from S3 into a new table; full-table export to S3 with no performance impact for analytics.

Limits

• Item size: 400 KB.
• Partition key size: 2,048 bytes.
• Sort key size: 1,024 bytes.
• Page size for Query/Scan: 1 MB.
• 40,000 RCU and 40,000 WCU per table default (raisable via Service Quotas).

Common Use Cases

1. Session stores — web and mobile apps, gaming sessions, shopping carts.
2. User profile and metadata stores — low-latency reads for personalization at scale.
3. Gaming leaderboards and player state — partition by player or match; use GSIs for ranking.
4. IoT telemetry — billions of sensor writes with TTL for cost control, optionally streamed to Kinesis.
5. Event-driven microservices — DynamoDB Streams + Lambda for CDC-style fan-out.
6. Ad-tech / real-time bidding — single-digit-millisecond reads with DAX for microsecond hot paths.
7. Financial ledgers — strong consistency + transactions for journals, balances, and audit trails.

Pricing Model

• On-Demand: per million read/write request units. DynamoDB scales instantly, but per-request cost is higher than equivalent provisioned capacity.
• Provisioned: per hour per RCU/WCU. Typically 15–70% cheaper than On-Demand for predictable workloads; combine with auto scaling and optional Reserved Capacity for additional savings.
• Storage: per GB-month after the first 25 GB of Always Free Tier.
• Optional features: Streams (per read unit), Global Tables (replicated write request units across Regions), DAX (per node-hour), backups (per GB-month), PITR (per GB-month).
• Data transfer: standard AWS rates out of the Region.

The Always Free Tier includes 25 GB storage, 25 RCU, 25 WCU, and roughly 200 million requests per month — enough to run many small applications indefinitely.

Pros and Cons

Pros

• Truly serverless — no servers, no patching, automatic multi-AZ durability.
• Single-digit millisecond performance at any scale.
• Unlimited storage and virtually unlimited throughput with On-Demand.
• Deep integration with Lambda, EventBridge, Step Functions, and the rest of AWS.
• Strong consistency, transactions, Global Tables, TTL — features many NoSQL engines lack.

Cons

• No ad-hoc relational queries — you must model access patterns up front; adding a new query often means adding a GSI.
• 400 KB item size limit forces large blobs into S3 with a pointer in DynamoDB.
• Cost modeling can be surprising (hot-partition penalties, GSI overhead) until you learn the patterns.
• Scans are expensive and should be avoided in hot paths.
• Joins, aggregations, and complex analytics require exporting to S3 / Athena / Redshift.

Comparison with Alternatives

| | DynamoDB | RDS / Aurora | ElastiCache | MongoDB Atlas | | --- | --- | --- | --- | --- | | Data model | Key-value / document | Relational | In-memory cache | Document | | Management | Fully managed, serverless | Managed, instance-based | Managed, instance-based | Managed, instance-based | | Latency | Single-digit ms (µs with DAX) | ms | sub-ms | ms | | Schema | Flexible (only PK required) | Strict | Opaque | Flexible | | Transactions | ACID within service | ACID | No | ACID (limited) | | Cost model | Pay per capacity / request | Per instance-hour | Per node-hour | Per cluster | | Best for | Predictable-access NoSQL at scale | Structured queries, joins | Hot cache | Flexible document DB |

Rule of thumb: if you can model the workload by its access patterns (queries by partition key with optional sort), DynamoDB. If you need ad-hoc SQL, RDS or Aurora.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — partition key design, GSI vs LSI, On-Demand vs Provisioned, DynamoDB Streams + Lambda patterns, Global Tables for multi-Region.
• Developer Associate (DVA-C02) — heavy coverage: single-item operations, BatchGetItem/BatchWriteItem, conditional writes, transactions, optimistic concurrency control, TTL, DAX.
• Database Specialty (DBS-C01) — capacity planning, adaptive capacity, backup/PITR, data modeling workshops, migration strategies.

Frequent exam trap: LSIs must be defined at table creation and cannot be added later; GSIs can be added and dropped any time. A question mentioning "different sort key but same partition key" and "strong consistency needed" points to an LSI; a question mentioning "different partition key" or "ad-hoc access pattern" points to a GSI.

Frequently Asked Questions

Q: What's the difference between a Global Secondary Index and a Local Secondary Index?

A: A Global Secondary Index (GSI) has a different partition key (and optional sort key) than the base table and can be created or dropped at any time; reads are eventually consistent by default, and GSIs have their own throughput in provisioned mode. A Local Secondary Index (LSI) shares the base table's partition key but uses a different sort key; it must be created at table creation, supports strong consistency, and draws from the table's throughput. Use GSIs for flexibility and late-added queries; use LSIs when you need strong-consistency range queries on the same partition.

Q: When should I pick On-Demand over Provisioned capacity?

A: Use On-Demand when traffic is unpredictable, spiky, or you're early in a project and don't know peak load — it scales instantly and you never pay for unused capacity. Use Provisioned when traffic is steady or predictable; it's typically 15–70% cheaper at scale and can be combined with Application Auto Scaling and Reserved Capacity for further savings. You can switch modes every 24 hours.

Q: How does DynamoDB achieve single-digit millisecond latency?

A: Data is partitioned by a hash of the partition key and stored on SSDs across three Availability Zones; requests are routed directly to the partition holding the item. Because DynamoDB does not scan or join across partitions for basic reads, latency is independent of table size. For even lower (microsecond) latency on hot read patterns, use DAX, the in-cluster write-through cache; for multi-Region sub-second reads, use Global Tables.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon DynamoDB documentation before making production decisions.