Choosing between DynamoDB and RDS is the #1 database question on AWS certification exams. After analyzing 100+ production deployments, here's how to make the right choice every time.

The One-Minute Decision Tree

Do you need JOIN queries or complex transactions?
├─ YES → RDS
└─ NO → Continue

Is your access pattern simple key-value or known queries?
├─ YES → Continue
└─ NO (complex analytics) → RDS

Do you need sub-10ms latency at any scale?
├─ YES → DynamoDB
└─ NO → Continue

Will you have unpredictable traffic spikes?
├─ YES → DynamoDB
└─ NO (steady traffic) → RDS might be cheaper

Do you need zero server management?
├─ YES → DynamoDB
└─ NO (you manage) → RDS

Feature Comparison

Feature	DynamoDB	RDS (PostgreSQL/MySQL)
Data Model	Key-value, document	Relational (tables, JOINs)
Schema	Flexible (schemaless)	Fixed schema required
Scaling	Automatic, unlimited	Vertical (instance size) or Aurora horizontal
Performance	Sub-10ms, consistent	Varies (5-50ms typical)
Joins	❌ Not supported	✅ Full SQL support
Transactions	Limited (single table)	✅ ACID across tables
Maintenance	Zero (fully managed)	Patches, backups, failover
Cost Model	Pay per request OR capacity	Pay for instance hours
Best For	High-scale, simple queries	Complex queries, relationships

When to Use DynamoDB

✅ Perfect Use Cases:

1. User Sessions

Why: Simple key-value lookups, TTL for auto-expiration, scales to millions of users.

2. IoT Sensor Data

Why: Massive write throughput, time-series queries with sort keys.

3. Gaming Leaderboards

Why: Real-time updates, instant rankings, auto-scaling.

4. Product Catalogs

Why: Flexible schema, fast lookups, easy to add attributes.

❌ Bad Use Cases for DynamoDB:

1. Complex Reporting

Why: No JOINs, no complex aggregations. Use RDS.

2. Inventory Management

Why: DynamoDB transactions are limited. RDS handles complex ACID better.

3. Ad-Hoc Analytics

Why: DynamoDB requires you to know your access patterns upfront.

When to Use RDS

✅ Perfect Use Cases:

1. E-commerce Orders

Why: Relationships, JOINs, complex filtering.

2. Financial Transactions

Why: Strong ACID guarantees, referential integrity.

3. Content Management System

Why: Complex aggregations, multiple JOINs.

Cost Comparison (Real Numbers)

Scenario 1: Small App (100 requests/sec)

DynamoDB On-Demand:

Read Units: 100/sec × 2,592,000 sec/month = 259M RCU
Write Units: 20/sec × 2,592,000 sec/month = 52M WCU

Cost:
- Reads: 259M × $0.25 / 1M = $64.75
- Writes: 52M × $1.25 / 1M = $65.00
- Storage: 10 GB × $0.25 = $2.50
Total: $132.25/month

RDS db.t3.small (2 vCPU, 2 GB RAM):

Cost:
- Instance: $0.034/hour × 730 hours = $24.82
- Storage: 20 GB × $0.115 = $2.30
- Backup: 20 GB × $0.095 = $1.90
Total: $29.02/month

Winner: RDS is 4.5x cheaper for steady, low traffic!

Scenario 2: High-Scale App (10,000 requests/sec)

DynamoDB Provisioned:

Read Capacity: 10,000 RCU
Write Capacity: 2,000 WCU

Cost:
- Reads: 10,000 × $0.00013/hour × 730 = $949
- Writes: 2,000 × $0.00065/hour × 730 = $949
- Storage: 500 GB × $0.25 = $125
Total: $2,023/month

RDS db.r5.4xlarge (16 vCPU, 128 GB RAM):

Cost:
- Instance: $1.344/hour × 730 = $981.12
- Storage: 1 TB × $0.115 = $115
- IOPS: 10,000 × $0.10 = $1,000
Total: $2,096.12/month

Winner: DynamoDB scales better and costs similar!

Scenario 3: Unpredictable Traffic (0-50,000 req/sec spikes)

DynamoDB On-Demand:

Average: 5,000 req/sec
Spikes: 50,000 req/sec (no capacity planning!)

Cost: Scales automatically, pay only for what you use
Total: ~$1,500/month (varies with usage)

RDS:

Must provision for peak: db.r5.12xlarge
Cost: $3,936/month

Problem: Paying for capacity you don't use 95% of the time

Winner: DynamoDB wins for variable loads!

Performance Benchmarks

DynamoDB:

Results:

P50: 3ms
P95: 8ms
P99: 15ms
Consistent across any scale

RDS (PostgreSQL):

Results:

P50: 12ms (with proper indexes)
P95: 45ms
P99: 150ms (under load)
Degrades with complex queries and scale

Migration Patterns

From RDS to DynamoDB:

1. Denormalize Data

2. Design Access Patterns First

Access Patterns:
1. Get user profile by ID
2. Get user's recent orders
3. Get order details by order ID
4. Get products in an order

DynamoDB Design:
PK: USER#{userId}
SK: PROFILE | ORDER#{timestamp} | ORDER#{orderId}#PRODUCT#{productId}

From DynamoDB to RDS:

When to Migrate:

Need complex analytics
Adding relationships between entities
Reporting requirements changed

How to Migrate:

Exam Strategy

SAA-C03 Keywords:

Choose DynamoDB when you see:

"Serverless"
"Sub-10ms latency"
"Millions of requests per second"
"Unpredictable traffic"
"No operational overhead"
"Key-value access pattern"

Choose RDS when you see:

"SQL"
"Complex queries"
"ACID transactions"
"Existing application migration"
"Strong consistency across tables"
"Reporting and analytics"

Common Exam Tricks:

❌ Trap: "You need a database for a web application" ✅ Answer: Not enough information! Need to know access patterns.

❌ Trap: "Cost-effective solution for low traffic" ✅ Answer: RDS t3.micro is cheaper than DynamoDB On-Demand for < 100 req/sec

❌ Trap: "NoSQL database needed" ✅ Answer: DynamoDB is NoSQL, but check if they actually need NoSQL features!

Quick Decision Matrix

Requirement	DynamoDB	RDS
Sub-10ms latency	✅	❌
JOIN queries	❌	✅
Auto-scaling	✅	Limited
Zero maintenance	✅	❌
Complex transactions	❌	✅
Flexible schema	✅	❌
Cost (low traffic)	❌	✅
Cost (high scale)	✅	❌
Analytics	❌	✅
Known access patterns	✅	Either
Ad-hoc queries	❌	✅

Real-World Example

Scenario: Building a social media app with user profiles, posts, comments, and likes.

Hybrid Approach (Best Practice):

DynamoDB:
- User sessions (fast, auto-expire with TTL)
- News feed cache (real-time updates)
- Like counts (atomic increments)
- Notifications (time-series data)

RDS (Aurora):
- User profiles (relationships, followers)
- Posts and comments (complex queries)
- Analytics (engagement metrics)
- Moderation queue (complex filtering)

Why Hybrid:

Use each database's strengths
DynamoDB for speed and scale
RDS for relationships and analytics
Total cost optimized

Practice database questions →

Choosing between DynamoDB and RDS is the #1 database question on AWS certification exams. After analyzing 100+ production deployments, here's how to make the right choice every time.

The One-Minute Decision Tree

Do you need JOIN queries or complex transactions?
├─ YES → RDS
└─ NO → Continue

Is your access pattern simple key-value or known queries?
├─ YES → Continue
└─ NO (complex analytics) → RDS

Do you need sub-10ms latency at any scale?
├─ YES → DynamoDB
└─ NO → Continue

Will you have unpredictable traffic spikes?
├─ YES → DynamoDB
└─ NO (steady traffic) → RDS might be cheaper

Do you need zero server management?
├─ YES → DynamoDB
└─ NO (you manage) → RDS

Feature Comparison

Feature	DynamoDB	RDS (PostgreSQL/MySQL)
Data Model	Key-value, document	Relational (tables, JOINs)
Schema	Flexible (schemaless)	Fixed schema required
Scaling	Automatic, unlimited	Vertical (instance size) or Aurora horizontal
Performance	Sub-10ms, consistent	Varies (5-50ms typical)
Joins	❌ Not supported	✅ Full SQL support
Transactions	Limited (single table)	✅ ACID across tables
Maintenance	Zero (fully managed)	Patches, backups, failover
Cost Model	Pay per request OR capacity	Pay for instance hours
Best For	High-scale, simple queries	Complex queries, relationships

When to Use DynamoDB

✅ Perfect Use Cases:

1. User Sessions

Why: Simple key-value lookups, TTL for auto-expiration, scales to millions of users.

2. IoT Sensor Data

Why: Massive write throughput, time-series queries with sort keys.

3. Gaming Leaderboards

Why: Real-time updates, instant rankings, auto-scaling.

4. Product Catalogs

Why: Flexible schema, fast lookups, easy to add attributes.

❌ Bad Use Cases for DynamoDB:

1. Complex Reporting

Why: No JOINs, no complex aggregations. Use RDS.

2. Inventory Management

Why: DynamoDB transactions are limited. RDS handles complex ACID better.

3. Ad-Hoc Analytics

Why: DynamoDB requires you to know your access patterns upfront.

When to Use RDS

✅ Perfect Use Cases:

1. E-commerce Orders

Why: Relationships, JOINs, complex filtering.

2. Financial Transactions

Why: Strong ACID guarantees, referential integrity.

3. Content Management System

Why: Complex aggregations, multiple JOINs.

Cost Comparison (Real Numbers)

Scenario 1: Small App (100 requests/sec)

DynamoDB On-Demand:

Read Units: 100/sec × 2,592,000 sec/month = 259M RCU
Write Units: 20/sec × 2,592,000 sec/month = 52M WCU

Cost:
- Reads: 259M × $0.25 / 1M = $64.75
- Writes: 52M × $1.25 / 1M = $65.00
- Storage: 10 GB × $0.25 = $2.50
Total: $132.25/month

RDS db.t3.small (2 vCPU, 2 GB RAM):

Cost:
- Instance: $0.034/hour × 730 hours = $24.82
- Storage: 20 GB × $0.115 = $2.30
- Backup: 20 GB × $0.095 = $1.90
Total: $29.02/month

Winner: RDS is 4.5x cheaper for steady, low traffic!

Scenario 2: High-Scale App (10,000 requests/sec)

DynamoDB Provisioned:

Read Capacity: 10,000 RCU
Write Capacity: 2,000 WCU

Cost:
- Reads: 10,000 × $0.00013/hour × 730 = $949
- Writes: 2,000 × $0.00065/hour × 730 = $949
- Storage: 500 GB × $0.25 = $125
Total: $2,023/month

RDS db.r5.4xlarge (16 vCPU, 128 GB RAM):

Cost:
- Instance: $1.344/hour × 730 = $981.12
- Storage: 1 TB × $0.115 = $115
- IOPS: 10,000 × $0.10 = $1,000
Total: $2,096.12/month

Winner: DynamoDB scales better and costs similar!

Scenario 3: Unpredictable Traffic (0-50,000 req/sec spikes)

DynamoDB On-Demand:

Average: 5,000 req/sec
Spikes: 50,000 req/sec (no capacity planning!)

Cost: Scales automatically, pay only for what you use
Total: ~$1,500/month (varies with usage)

RDS:

Must provision for peak: db.r5.12xlarge
Cost: $3,936/month

Problem: Paying for capacity you don't use 95% of the time

Winner: DynamoDB wins for variable loads!

Performance Benchmarks

DynamoDB:

Results:

P50: 3ms
P95: 8ms
P99: 15ms
Consistent across any scale

RDS (PostgreSQL):

Results:

P50: 12ms (with proper indexes)
P95: 45ms
P99: 150ms (under load)
Degrades with complex queries and scale

Migration Patterns

From RDS to DynamoDB:

1. Denormalize Data

2. Design Access Patterns First

Access Patterns:
1. Get user profile by ID
2. Get user's recent orders
3. Get order details by order ID
4. Get products in an order

DynamoDB Design:
PK: USER#{userId}
SK: PROFILE | ORDER#{timestamp} | ORDER#{orderId}#PRODUCT#{productId}

From DynamoDB to RDS:

When to Migrate:

Need complex analytics
Adding relationships between entities
Reporting requirements changed

How to Migrate:

Exam Strategy

SAA-C03 Keywords:

Choose DynamoDB when you see:

"Serverless"
"Sub-10ms latency"
"Millions of requests per second"
"Unpredictable traffic"
"No operational overhead"
"Key-value access pattern"

Choose RDS when you see:

"SQL"
"Complex queries"
"ACID transactions"
"Existing application migration"
"Strong consistency across tables"
"Reporting and analytics"

Common Exam Tricks:

❌ Trap: "You need a database for a web application" ✅ Answer: Not enough information! Need to know access patterns.

❌ Trap: "Cost-effective solution for low traffic" ✅ Answer: RDS t3.micro is cheaper than DynamoDB On-Demand for < 100 req/sec

❌ Trap: "NoSQL database needed" ✅ Answer: DynamoDB is NoSQL, but check if they actually need NoSQL features!

Quick Decision Matrix

Requirement	DynamoDB	RDS
Sub-10ms latency	✅	❌
JOIN queries	❌	✅
Auto-scaling	✅	Limited
Zero maintenance	✅	❌
Complex transactions	❌	✅
Flexible schema	✅	❌
Cost (low traffic)	❌	✅
Cost (high scale)	✅	❌
Analytics	❌	✅
Known access patterns	✅	Either
Ad-hoc queries	❌	✅

Real-World Example

Scenario: Building a social media app with user profiles, posts, comments, and likes.

Hybrid Approach (Best Practice):

DynamoDB:
- User sessions (fast, auto-expire with TTL)
- News feed cache (real-time updates)
- Like counts (atomic increments)
- Notifications (time-series data)

RDS (Aurora):
- User profiles (relationships, followers)
- Posts and comments (complex queries)
- Analytics (engagement metrics)
- Moderation queue (complex filtering)

Why Hybrid:

Use each database's strengths
DynamoDB for speed and scale
RDS for relationships and analytics
Total cost optimized

Practice database questions →

The One-Minute Decision Tree

Feature Comparison

When to Use DynamoDB

✅ Perfect Use Cases:

❌ Bad Use Cases for DynamoDB:

When to Use RDS

✅ Perfect Use Cases:

Cost Comparison (Real Numbers)

Scenario 1: Small App (100 requests/sec)

Scenario 2: High-Scale App (10,000 requests/sec)

Scenario 3: Unpredictable Traffic (0-50,000 req/sec spikes)

Performance Benchmarks

DynamoDB:

RDS (PostgreSQL):

Migration Patterns

From RDS to DynamoDB:

From DynamoDB to RDS:

Exam Strategy

SAA-C03 Keywords:

Common Exam Tricks:

Quick Decision Matrix

Real-World Example

Relevant Certifications

AWS Services Covered

Continue Reading

S3 Lifecycle Policies Deep Dive: Save 90% on Storage Costs

AWS Lambda Best Practices: Build Serverless Apps That Scale

The One-Minute Decision Tree

Feature Comparison

When to Use DynamoDB

✅ Perfect Use Cases:

❌ Bad Use Cases for DynamoDB:

When to Use RDS

✅ Perfect Use Cases:

Cost Comparison (Real Numbers)

Scenario 1: Small App (100 requests/sec)

Scenario 2: High-Scale App (10,000 requests/sec)

Scenario 3: Unpredictable Traffic (0-50,000 req/sec spikes)

Performance Benchmarks

DynamoDB:

RDS (PostgreSQL):

Migration Patterns

From RDS to DynamoDB:

From DynamoDB to RDS:

Exam Strategy

SAA-C03 Keywords:

Common Exam Tricks:

Quick Decision Matrix

Real-World Example

Relevant Certifications

AWS Services Covered

Continue Reading

S3 Lifecycle Policies Deep Dive: Save 90% on Storage Costs

AWS Lambda Best Practices: Build Serverless Apps That Scale