RDS vs Aurora vs DynamoDB: Choosing a Database on AWS
Database selection questions on the exam describe access patterns — query type, scale, structure — and expect you to pick the fitting engine. The split is simple at heart: relational (RDS/Aurora) vs NoSQL key-value (DynamoDB).
RDS — managed relational
RDS runs PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server with managed backups, patching, and failover. Choose it when you need SQL, joins, transactions, or a specific engine. Scale reads with read replicas; get HA with Multi-AZ.
Aurora — cloud-native relational
Aurora is MySQL/PostgreSQL-compatible but re-architected for the cloud: storage replicated six ways across three AZs, up to 15 low-lag read replicas, and faster failover. Aurora Serverless v2 scales capacity automatically — good for variable loads and cost control. Choose Aurora when the workload is relational but demands more performance or resilience than community engines, or cross-Region DR via Global Database.
DynamoDB — serverless NoSQL
DynamoDB provides single-digit-millisecond key-value/document access at effectively unlimited scale with zero infrastructure management. On-demand mode bills per request — perfect for spiky workloads. Global tables give multi-Region active-active. Choose it for session stores, user profiles, catalogs, leaderboards — anything accessed by key rather than relational queries.
Quick decision table
- Need SQL, joins, transactions, specific engine (Oracle, SQL Server) → RDS
- MySQL/PostgreSQL-compatible, higher performance or global DR → Aurora
- Key-value access, unpredictable scale, single-digit-ms, serverless billing → DynamoDB
- In-memory caching of hot reads → ElastiCache or DAX on top