Amazon DynamoDB

Definition

Amazon DynamoDB is a fully managed, serverless NoSQL database that provides single-digit millisecond read and write performance at any scale — from a few records to trillions. DynamoDB requires no capacity planning, no schema migrations, and scales automatically. It is the database of choice for high-throughput applications, gaming leaderboards, IoT data, session stores, and event-driven architectures on AWS.

Data Model

DynamoDB stores data as items (equivalent to rows) in tables. Each item is a collection of attributes (key-value pairs). Schema is flexible — different items in the same table can have different attributes.

Primary Key (required, identifies each item uniquely):

• Partition Key only: A single attribute that DynamoDB hashes to determine storage partition (e.g., userId)
• Composite Key: Partition Key + Sort Key — allows multiple items per partition, sorted by sort key (e.g., userId + orderTimestamp)

Secondary Indexes (optional, for additional query patterns):

• Global Secondary Index (GSI): Query on any attribute, different partition key
• Local Secondary Index (LSI): Query on same partition key with alternate sort key

Capacity Modes

On-Demand Capacity

• Pay per read/write request, no capacity planning
• Scales instantly to any traffic level
• Best for unpredictable or spiky workloads
• More expensive per request than provisioned at steady-state

Provisioned Capacity

• Specify Read Capacity Units (RCUs) and Write Capacity Units (WCUs)
• Use Auto Scaling to adjust automatically based on utilization
• Combine with Reserved Capacity (similar to Savings Plans) for up to 77% savings
• Best for predictable, steady-state workloads

Key Features

DynamoDB Streams

• Ordered stream of item-level changes (inserts, updates, deletes)
• Trigger Lambda functions on data changes — foundation for event-driven architectures
• 24-hour retention; near-real-time (< 1 second latency)

Global Tables

• Multi-region, multi-active replication
• Write to any region; changes replicate globally in under 1 second
• Built-in conflict resolution using “last writer wins”
• Used for globally distributed applications requiring low-latency local writes

DynamoDB Accelerator (DAX)

• In-memory cache for DynamoDB
• Reduces read latency from milliseconds to microseconds
• API-compatible — no code changes required
• Best for read-heavy workloads (gaming, real-time bidding, social feeds)

Point-in-Time Recovery (PITR)

• Continuous backups with 35-day recovery window
• Restore to any second within the window

DynamoDB vs RDS: When to Use Each

Use DynamoDB when: you have 1–3 known access patterns, need single-digit ms latency at scale, or want true serverless with zero database management.

Use RDS when: you need complex SQL queries, ad-hoc reporting, multi-table joins, or are migrating an existing relational workload.

Common Mistakes

Mistake 1: Designing a table without thinking about access patterns first. DynamoDB requires upfront data modeling — queries must align with your primary key and index design. Adding a new query pattern later may require table restructuring.

Mistake 2: Using on-demand mode for predictable, high-throughput workloads. Provisioned capacity + auto scaling + reserved capacity is significantly cheaper for steady workloads.

Mistake 3: Storing large objects directly in DynamoDB items. DynamoDB items have a 400 KB limit. Store large payloads (images, documents) in S3 and keep a reference key in DynamoDB.

Related AWS Services

• AWS Lambda + DynamoDB Streams: Event-driven architectures triggered by table changes
• Amazon DAX: Microsecond caching layer for DynamoDB
• AWS AppSync: GraphQL API layer over DynamoDB for mobile/web backends
• Amazon S3: Companion storage for large objects referenced by DynamoDB items

Related FactualMinds Content

• AWS RDS Consulting
• AWS Migration Services — MongoDB and Cassandra migrations to DynamoDB, Keyspaces, or DocumentDB
• AWS Serverless Services
• Cloud Cost Optimization