Databases
Choosing a database
Database selection questions give you an access pattern and constraints, and ask for the best fit. This chapter condenses the previous ones into decision tables and covers moving databases to AWS.
Start from the access pattern
| If the requirement mentions… | Consider |
|---|---|
| Joins, complex queries, transactions, existing SQL app | RDS or Aurora |
| Need for very high relational performance, many replicas, global DR | Aurora (Global Database) |
| Variable/intermittent relational load | Aurora Serverless v2 |
| Key-value access at massive scale, serverless | DynamoDB |
| Microsecond reads in front of DynamoDB | DAX |
| Cache, sessions, leaderboards | ElastiCache |
| JSON documents, MongoDB compatibility | DocumentDB |
| Highly connected data, relationships | Neptune |
| Time-stamped metrics/telemetry | Timestream |
| Cassandra workloads | Keyspaces |
| Analytics/BI over large datasets, columnar storage | Redshift |
| Ad-hoc SQL directly on files in S3 | Athena |
| Full-text search, log analytics | OpenSearch Service |
Relational engine choice (task 3.3 and 4.3)
| Need | Engine hint |
|---|---|
| Open source, widely used, simple | MySQL / MariaDB |
| Advanced SQL features, extensions (e.g. PostGIS, JSONB), strict standards | PostgreSQL |
| Commercial licences already owned | Oracle / SQL Server (licence-included or BYOL) |
| Lowest licensing cost | Open-source engines, possibly via migration from commercial ones |
Cost levers for databases
- Right-size instances (Compute Optimizer and Performance Insights help).
- Reserved instances for steady RDS/Aurora/ElastiCache/Redshift usage.
- Serverless options (Aurora Serverless v2, DynamoDB on-demand) for intermittent load.
- DynamoDB provisioned + auto scaling for predictable traffic.
- Caching to reduce expensive reads.
- Storage tiering — DynamoDB Standard-IA table class, snapshot archive, S3 exports for cold data.
- Data retention — TTL, lifecycle policies, shorter backup retention where allowed.
- Columnar formats (Redshift, Parquet on S3) for analytics.
Migrating databases
Homogeneous vs heterogeneous
| Migration | Example | Tools |
|---|---|---|
| Homogeneous (same engine) | On-prem MySQL → RDS MySQL | Native tools (dump/restore, replication) or AWS DMS |
| Heterogeneous (different engine) | Oracle → Aurora PostgreSQL | Schema conversion (AWS SCT / DMS Schema Conversion) then AWS DMS for data |
AWS Database Migration Service (DMS)
- Migrates data with the source database remaining operational.
- Full load + ongoing replication (change data capture, CDC) for minimal-downtime cutovers.
- Sources and targets include most commercial and open-source databases, S3, DynamoDB, Redshift, Kinesis and more.
- Runs on a replication instance (or serverless).
Key idea
"Migrate Oracle to Aurora PostgreSQL with minimal downtime" → schema conversion (SCT/DMS Schema Conversion) + DMS with CDC.
Exam patterns
- "Unpredictable traffic, millions of users, simple key lookups, minimal management" → DynamoDB on-demand.
- "Heavy analytics queries over years of sales data" → Redshift (or Athena on S3 Parquet).
- "Move SQL Server to AWS with the least change" → RDS for SQL Server (rehost/replatform).
- "Cut licensing costs by leaving Oracle" → heterogeneous migration to Aurora PostgreSQL.
Written by Bipin Singh
Work with meSenior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.