RDS vs Aurora vs DynamoDB: AWS Database Selection Guide

Key Takeaway

Choose RDS/Aurora for SQL data and complex queries, DynamoDB for unlimited scaling and millisecond latency. Aurora is the high-performance version of RDS (5x MySQL, 3x PostgreSQL faster), and DynamoDB is fully serverless NoSQL.

---

Three Services at a Glance

Comparison	RDS	Aurora	DynamoDB
Data Model	Relational (SQL)	Relational (SQL)	Non-relational (NoSQL)
Supported Engines	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server	MySQL, PostgreSQL	Key-value, Document
Max Storage	64TiB	128TiB (auto-scaling)	Unlimited
Read Replicas	Up to 5	Up to 15	Global Tables
Auto Failover	Requires Multi-AZ	Built-in	Built-in
Serverless Option	❌	✅ Aurora Serverless	✅ Fully serverless
Management Level	Managed	Managed	Fully managed
Cost Model	Instance + Storage	Instance + I/O	RCU/WCU or On-demand

---

Amazon RDS

What is RDS?

RDS (Relational Database Service) is a managed service that makes it easy to set up, operate, and scale relational databases. It automates hardware provisioning, database setup, patching, and backups.

RDS Management Scope:

AWS Manages           │ You Manage
──────────────────────┼──────────────────
Hardware              │ Schema design
OS patches            │ Query optimization
DB engine patches     │ Index management
Backups               │ Application code
High availability     │ Parameter tuning

RDS Supported Database Engines

Engine	Features	Best For
MySQL	Open source, most common	Web apps, general purpose
PostgreSQL	Advanced features, GIS support	Complex queries, analytics
MariaDB	MySQL fork, community-driven	MySQL alternative
Oracle	Enterprise features	Existing Oracle workloads
SQL Server	Microsoft ecosystem	.NET applications

RDS Ideal Use Cases

• Traditional OLTP workloads: Transaction processing
• On-premises migration: Minimal code changes
• Complex JOIN queries: Relational data model
• Oracle/SQL Server licenses: BYOL (Bring Your Own License)

---

Amazon Aurora

What is Aurora?

Aurora is a cloud-native relational database that is MySQL and PostgreSQL compatible while providing up to 5x (MySQL) or 3x (PostgreSQL) better performance.

Aurora Architecture:

                ┌─────────────────────────────────────┐
                │     Aurora Storage Cluster          │
                │  (6 copies auto-distributed in 3 AZs) │
                │                                     │
                │   AZ-a    │    AZ-b    │    AZ-c   │
                │   ██ ██   │   ██ ██   │   ██ ██   │
                └─────────────────────────────────────┘
                          ↑               ↑
                    ┌─────────────┐ ┌─────────────┐
                    │   Writer    │ │   Reader    │
                    │ (Primary)   │ │ (Replica)   │
                    └─────────────┘ └─────────────┘
                          ↑               ↑
                       Writes        Reads (up to 15)

Aurora vs RDS Comparison

Item	RDS	Aurora
Performance	Baseline	MySQL 5x, PostgreSQL 3x
Storage	Manual provisioning (max 64TiB)	Auto-scaling (max 128TiB)
Replicas	Up to 5	Up to 15
Replication Lag	Seconds	Milliseconds
Failover	1-2 minutes	~30 seconds
Backup	S3 backup	Continuous, incremental
Cost	Lower	20-30% higher

Aurora Unique Features

1. Aurora Serverless v2

Auto-scales based on usage:
- Charged per ACU (Aurora Capacity Unit)
- Auto-adjusts between 0.5-128 ACUs
- Ideal for dev/test environments

2. Aurora Global Database

Sub-second global replication:
- 1 primary region + up to 5 secondary regions
- Sub-second reads from secondary regions
- RTO < 1 minute disaster recovery

3. Aurora Cloning

Clone TB-scale databases in seconds:
- Copy-on-Write method
- No impact on source data
- Perfect for test environments

Aurora Ideal Use Cases

• High-performance OLTP: When exceeding MySQL/PostgreSQL limits
• Read-heavy workloads: Utilize 15 read replicas
• Variable traffic: Cost optimization with Aurora Serverless
• Global applications: Reduce latency with Global Database

---

Amazon DynamoDB

What is DynamoDB?

DynamoDB is a fully managed NoSQL database that delivers single-digit millisecond performance at any scale. Server provisioning, patching, and scaling are fully automated.

DynamoDB Data Model:

Table: Users
┌─────────────────────────────────────────────────┐
│ Partition Key │ Sort Key  │ Attributes          │
├───────────────┼───────────┼─────────────────────┤
│ user_001      │ profile   │ {name, email, ...}  │
│ user_001      │ order#001 │ {items, total, ...} │
│ user_001      │ order#002 │ {items, total, ...} │
│ user_002      │ profile   │ {name, email, ...}  │
└─────────────────────────────────────────────────┘
        ↓
   Data distributed by partition key → Unlimited horizontal scaling

DynamoDB Core Concepts

Concept	Description
Table	Data collection (schemaless)
Item	Each record in table
Attribute	Data field in item
Partition Key	Data distribution criteria (required)
Sort Key	Sorting within partition (optional)
GSI/LSI	Secondary indexes (support different query patterns)

DynamoDB Capacity Modes

1. Provisioned Capacity

- RCU (Read Capacity Unit): Read units per second
- WCU (Write Capacity Unit): Write units per second
- Best for predictable traffic
- Auto Scaling available

2. On-Demand Capacity

- Pay per request
- No capacity planning needed
- Best for unpredictable traffic
- ~2.5x cost vs provisioned

DynamoDB Unique Features

1. DynamoDB Streams

Real-time capture of table changes:
INSERT/UPDATE/DELETE → Stream → Lambda trigger
- Real-time event processing
- Data replication/sync

2. Global Tables

Multi-region replication:
Seoul ↔ Virginia ↔ Frankfurt
- Automatic multi-master replication
- Local reads/writes (low latency)
- Auto-failover on region failure

3. DAX (DynamoDB Accelerator)

In-memory cache:
Application → DAX → DynamoDB
- Microsecond response times
- Read-heavy workloads
- Apply without API changes

DynamoDB Ideal Use Cases

• Massive scale required: Millions of requests per second
• Low latency mandatory: Single-digit milliseconds
• Simple query patterns: Key-based lookups
• Serverless architecture: Lambda integration
• Session management: Auto-expire with TTL
• Gaming leaderboards: Fast reads/writes

---

Selection Criteria Guide

By Data Model

Data Type Decision Tree:

Are data relationships complex?
       │
       ├── YES: Need JOINs/transactions → Relational (RDS/Aurora)
       │           │
       │           ├── Standard performance sufficient → RDS
       │           └── High performance/auto-scale → Aurora
       │
       └── NO: Simple key-value lookups → DynamoDB

By Workload

Workload Characteristic	Recommended Service
Complex SQL queries	RDS/Aurora
ACID transactions	RDS/Aurora (DynamoDB has limited support)
Frequent schema changes	DynamoDB
10K+ requests/second	DynamoDB
Predictable performance	DynamoDB
Read-heavy (reporting)	Aurora (15 read replicas)
Fully serverless	DynamoDB / Aurora Serverless

---

SAA-C03 Exam Focus Points

1. ✅ Data model: Relational = RDS/Aurora, NoSQL = DynamoDB
2. ✅ Aurora performance: MySQL 5x, PostgreSQL 3x, 15 read replicas
3. ✅ DynamoDB characteristics: Serverless, unlimited scale, millisecond latency
4. ✅ Aurora storage: Auto-scaling, 128TiB, 6 copies
5. ✅ DynamoDB Global Tables: Multi-region multi-master
6. ✅ Capacity modes: Provisioned vs On-demand

---

Frequently Asked Questions

Q: Should I always choose Aurora over RDS?

No. Aurora performs better but costs 20-30% more. RDS is more suitable for small workloads, dev/test environments, or when Oracle/SQL Server is required.

Q: What if I need JOINs in DynamoDB?

Handle it at the application level. DynamoDB doesn't support JOINs, so you need to denormalize data or combine multiple query results in your application. Consider RDS/Aurora if you need many JOINs.

Q: When should I use Aurora Serverless?

When traffic is irregular or intermittent. Cost-effective for dev/test environments, workloads with no nighttime traffic, or unpredictable traffic. Provisioned instances are cheaper for consistent 24/7 traffic.

Q: How do I choose between DynamoDB Provisioned and On-demand?

Based on traffic predictability. If you know traffic patterns, Provisioned (with Auto Scaling) is cheaper. For unpredictable or new workloads, start with On-demand and consider switching after understanding patterns.

Q: Is migrating from RDS to Aurora easy?

Relatively easy for MySQL/PostgreSQL. You can create an Aurora cluster directly from an RDS snapshot. To minimize downtime, create an Aurora Read Replica and promote it.

Q: Can I use DynamoDB and Aurora together?

Yes, hybrid architecture is possible. A common pattern is storing transactional data in Aurora and session/cache/fast-lookup data in DynamoDB.

---

Related Posts

• RDS Multi-AZ vs Read Replica: When to Choose Which?
• DynamoDB Partition Key Design
• ElastiCache (Redis vs Memcached)

---

References

• Amazon RDS Official Documentation
• Amazon Aurora Official Documentation
• Amazon DynamoDB Official Documentation
• AWS Database Selection Guide