RDS vs DynamoDB vs Aurora: AWS Databases for SAA-C03 (2026)

Database questions on SAA-C03 are selection puzzles: the stem describes a workload and asks which managed database, or which feature of one, fits. Get the mental model of what each database is for and the questions become fast; guess between them and you will burn time and points. This guide covers the databases AWS tests and, more importantly, the decisions between them.

For the full service map, see the domains breakdown; this piece goes deep on the data layer.

The Big Split: Relational vs NoSQL

Start every database question by classifying the workload:

• Relational (SQL): structured data, joins, transactions, a fixed schema. AWS answers: RDS and Aurora.
• NoSQL (key-value / document): massive scale, flexible schema, predictable single-digit-millisecond access by key. AWS answer: DynamoDB.

The stem's language routes you: "complex queries and joins," "existing MySQL/PostgreSQL app," "ACID transactions" point relational; "millions of requests per second," "flexible schema," "single-digit millisecond latency at any scale" point DynamoDB.

RDS: Managed Relational, and the Multi-AZ vs Read Replica Trap

RDS runs managed MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. The most-tested RDS concept is a pair of features candidates confuse:

This single distinction appears on nearly every exam. Multi-AZ is availability; read replicas are read scaling. They are not substitutes, and a question can require both (a Multi-AZ primary plus read replicas for a read-heavy, HA app). A stem that says "reporting queries are slowing the production database" wants read replicas; one that says "the database must survive an Availability Zone outage" wants Multi-AZ.

Aurora: Cloud-Native Relational

Aurora is AWS's MySQL- and PostgreSQL-compatible database built for the cloud: storage auto-scales, data is replicated six ways across three AZs, and it delivers substantially higher throughput than standard RDS. Know:

• Up to 15 Aurora Replicas with fast failover; the replicas share the same storage volume, so replication lag is minimal.
• Aurora Serverless v2 scales capacity automatically for variable or unpredictable workloads; the "spiky relational load, don't manage capacity" answer.
• Global Database for cross-Region replication with low-latency reads and DR.

Aurora is the answer when a relational scenario stresses high throughput, high availability, or managed scaling beyond what plain RDS offers, and cost is not the overriding constraint.

DynamoDB: Serverless NoSQL at Scale

DynamoDB is a fully managed key-value and document store with single-digit-millisecond latency at any scale and no servers to manage. The exam-relevant mechanics:

• Partition (hash) key design drives performance; a poorly chosen key creates hot partitions. "Requests are throttling despite low overall usage" often means an uneven partition key.
• Capacity modes: On-Demand (pay per request, unpredictable traffic) vs Provisioned (cheaper for steady, predictable traffic, with optional auto-scaling).
• DAX (DynamoDB Accelerator): an in-memory cache giving microsecond reads; the "make DynamoDB reads even faster" answer.
• Global Tables: multi-Region, multi-active replication; the "low-latency global access and Region-level DR for a NoSQL store" answer.
• TTL: auto-expire items (sessions, temporary data) with no cost.

DynamoDB wins scenarios about serverless architectures, extreme scale, session stores, and flexible-schema data.

Caching and Analytics

Two databases that answer specific keywords:

• ElastiCache (Redis or Memcached): in-memory caching to offload read-heavy databases and cut latency. Redis when you need persistence, replication, or pub/sub; Memcached for simple, horizontally-sharded caching. The "reduce database load / speed up repeated reads" answer for relational workloads.
• Redshift: a columnar data warehouse for OLAP analytics over large datasets. The answer for "run complex analytical queries across terabytes," and the wrong answer for transactional (OLTP) workloads.

How This Shows Up on the Exam

• Reporting queries slow the production RDS database. (Add read replicas to offload reads.)
• The database must continue through an AZ failure with automatic failover. (Enable Multi-AZ.)
• A relational workload with unpredictable spikes and no desire to manage capacity. (Aurora Serverless v2.)
• A session store needing single-digit-ms reads at massive scale, serverless. (DynamoDB, with DAX if microsecond reads are required.)
• Complex analytics across terabytes of historical data. (Redshift, not RDS.)
• Repeated identical reads are hammering the database. (Put ElastiCache in front.)

Key Takeaways

• Classify first: relational (RDS/Aurora) vs NoSQL key-value (DynamoDB)
• Multi-AZ = availability/failover; read replicas = read scaling. Never interchangeable.
• Aurora for high-throughput, highly-available relational; Serverless v2 for variable load; Global Database for cross-Region
• DynamoDB for serverless scale; partition-key design matters; DAX for microsecond reads; Global Tables for multi-Region
• ElastiCache to offload read-heavy databases; Redshift for OLAP analytics, never OLTP

Continue with high availability and disaster recovery, or drill database scenarios in Preporato's SAA-C03 practice exams.

Sources:

• Amazon RDS Documentation
• Amazon DynamoDB Documentation
• Amazon Aurora Documentation

Last updated: July 10, 2026