DynamoDB

DynamoDB is Amazon Web Services' fully managed, serverless NoSQL database designed for applications requiring consistent single-digit millisecond latency at any scale—from startup prototypes to services handling trillions of requests daily. Unlike traditional databases requiring capacity planning, server provisioning, and maintenance, DynamoDB automatically scales throughput and storage based on traffic, handles replication across multiple availability zones, performs automatic backups, and requires zero administration. Data is stored as key-value pairs or documents (JSON) with flexible schemas. DynamoDB powers some of the world's largest applications (Amazon.com, Lyft, Samsung, Toyota) and integrates seamlessly with AWS ecosystem (Lambda, API Gateway, AppSync). Its serverless model means you pay only for actual usage, making it cost-effective for both low-traffic projects and massive scale.

Best For:
DynamoDB excels for serverless applications, microservices, and workloads requiring predictable performance at scale. It's ideal for serverless applications using AWS Lambda (auto-scales with your functions), mobile/IoT applications generating high-volume writes (device data, sensor readings, events), session storage requiring fast access and automatic expiration (TTL), real-time gaming leaderboards and player data, ad tech platforms serving billions of impressions, and applications with unpredictable traffic spikes (pay-per-request scales instantly). DynamoDB is particularly valuable on AWS infrastructure where tight integration with Lambda, API Gateway, CloudWatch, and other services reduces complexity. Its millisecond latency guarantees and automatic scaling eliminate performance concerns.

Common Questions

DynamoDB vs. MongoDB: which should I use?
Use DynamoDB for AWS-native serverless applications requiring predictable performance, automatic scaling, and zero operations. Use MongoDB for complex queries (aggregation pipelines, ad-hoc queries), rich query language, multi-cloud or on-premises deployments, or existing MongoDB expertise. DynamoDB has simpler query capabilities (key-based access, limited indexing) but scales automatically and integrates perfectly with AWS. MongoDB offers more flexible querying but requires more operations work (Atlas helps). DynamoDB is pay-per-request; MongoDB is typically instance-based. Choose DynamoDB for AWS-first, simple access patterns; MongoDB for query flexibility and portability.

How much does DynamoDB cost?
DynamoDB offers two pricing modes: On-Demand (pay-per-request, no capacity planning) charges $1.25 per million write requests, $0.25 per million read requests, $0.25/GB storage. Good for unpredictable traffic. Provisioned Capacity (fixed throughput) charges $0.00065/hour per write capacity unit, $0.00013/hour per read capacity unit, $0.25/GB storage. Better for predictable traffic (can be 7x cheaper). Free tier: 25 GB storage, 25 write units, 25 read units (enough for small apps indefinitely). DynamoDB can be expensive at scale without optimization—design access patterns carefully, use single-table design, compress data, leverage caching.

What are DynamoDB's query limitations?
DynamoDB is optimized for key-based access, not complex queries. You can query by partition key + optional sort key, but cannot scan all items efficiently, perform joins, or filter without indexes. Each query requires knowing the partition key. Secondary indexes enable additional access patterns but cost storage/throughput. Unlike SQL databases or MongoDB, DynamoDB requires designing your table schema around access patterns upfront. Trade-off: simpler query model but predictable performance. DynamoDB streams + Lambda can build materialized views for complex queries. Single-table design patterns help consolidate access patterns.

Can DynamoDB handle relational data?
DynamoDB is non-relational but can model relationships using single-table design patterns. Store different entity types in one table using composite keys and generic attribute names. Use adjacency list patterns for hierarchies. However, DynamoDB lacks foreign keys, joins, and referential integrity—you must manage relationships in application code. For heavily relational data requiring complex joins, PostgreSQL/RDS is better. For simple relationships with known access patterns, DynamoDB's single-table design works well. Consider hybrid: RDS for relational data, DynamoDB for high-scale key-value access.

Pricing & Plans

DynamoDB Free Tier (Permanent):

• 25 GB storage
• 25 provisioned write capacity units (200 million writes/month)
• 25 provisioned read capacity units (200 million reads/month)
• 2.5 million stream reads/month
• 1 GB data transfer out
  Free forever, even beyond 12-month AWS trial. Sufficient for small applications indefinitely.

On-Demand Pricing (Serverless, Pay-Per-Request):

• Write requests: $1.25 per million writes
• Read requests: $0.25 per million reads (eventually consistent), $0.50 per million (strongly consistent)
• Storage: $0.25/GB/month
• Data transfer: $0.09/GB out (to internet)
  No minimum fees. Scales automatically. Good for unpredictable traffic, development/testing, low traffic apps.

Example: 10M writes, 50M reads, 10 GB storage = $12.50 + $12.50 + $2.50 = $27.50/month

Provisioned Capacity (Reserved Throughput):

• Write capacity: $0.00065/hour per WCU (~$0.47/month per WCU)
• Read capacity: $0.00013/hour per RCU (~$0.09/month per RCU)
• Storage: $0.25/GB/month
• Auto-scaling available (adjusts capacity automatically)
  Better for predictable traffic (5-7x cheaper than on-demand at consistent load).

Example: 100 WCU, 500 RCU, 10 GB storage = $47 + $45 + $2.50 = $94.50/month

Additional Features (Optional):

• Point-in-time recovery (backups): $0.20/GB/month
• Global tables (multi-region): 2x write costs (replicate to second region)
• DynamoDB Streams: $0.02 per 100k read requests
• Backups on-demand: $0.10/GB/month

Limitations

DynamoDB requires designing table schema around access patterns upfront—you cannot easily add complex queries later like SQL databases. Maximum item size is 400 KB (use S3 for larger documents, store references in DynamoDB). Query capabilities are limited compared to SQL databases or MongoDB—no joins, limited filtering without indexes, scans are expensive. Each query requires partition key, making ad-hoc exploration difficult. DynamoDB strongly couples you to AWS—no on-premises option, no easy migration to other clouds (vendor lock-in). Costs can escalate quickly without careful optimization—frequent scans, many indexes, global tables, or inefficient access patterns cause bill shock. Transactions support up to 100 items across 4 MB—not suitable for complex multi-step transactions. Learning curve: single-table design, composite keys, and access pattern modeling require expertise (different from relational database thinking). DynamoDB is strongly consistent only within same region; global tables are eventually consistent.

Getting Started

Access DynamoDB via AWS Console, AWS CLI, or SDKs. Install AWS CLI: pip install awscli, configure: aws configure (requires AWS account and credentials). Create table:

# Create table (CLI)
aws dynamodb create-table \
  --table-name users \
  --attribute-definitions \
      AttributeName=userId,AttributeType=S \
  --key-schema \
      AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

# Put item
aws dynamodb put-item \
  --table-name users \
  --item '{"userId": {"S": "123"}, "email": {"S": "alice@example.com"}}'

# Get item
aws dynamodb get-item \
  --table-name users \
  --key '{"userId": {"S": "123"}}'

Use DynamoDB from your application (Python boto3 example: pip install boto3):

import boto3
dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table('users')

# Put item
table.put_item(Item={'userId': '123', 'email': 'alice@example.com', 'age': 30})

# Get item
response = table.get_item(Key={'userId': '123'})
print(response['Item'])

# Query (requires partition key)
response = table.query(
    KeyConditionExpression='userId = :id',
    ExpressionAttributeValues={':id': '123'}
)

Design table schema around access patterns using single-table design. Create Global Secondary Indexes (GSI) for additional query patterns. Use composite sort keys for hierarchical data. Enable DynamoDB Streams for change data capture. Use TTL (time-to-live) for automatic expiration. Monitor costs with AWS Cost Explorer. Learn single-table design from Alex DeBrie's "DynamoDB Book" and AWS documentation. Use NoSQL Workbench (free AWS tool) for data modeling and testing.