If you tallied every question on the SAA-C03 exam by topic, “which database should I use?” would be near the top. AWS gives you a dozen purpose-built database services, and the exam loves to describe a workload and ask you to pick the one that fits. Get the decision framework right and these become some of the fastest points on the test. Get it wrong and you’ll burn time second-guessing between two plausible answers.
This guide is written from a practitioner’s perspective. We’ll walk through the databases the SAA-C03 exam expects you to know cold — RDS, Aurora, DynamoDB, ElastiCache, and Redshift, plus the specialized engines — and, more importantly, the decision heuristics that turn a wall of options into a quick, confident choice. If you want the full exam picture first, start with the AWS Solutions Architect Associate Certification Guide 2026, then come back here to go deep on databases.
The First Fork: Relational vs. Non-Relational vs. Analytical
Before you can pick a service, you classify the workload. Almost every database question resolves along three axes:
| Workload signal | Category | AWS services |
|---|---|---|
| Structured data, joins, transactions, existing SQL app | Relational (OLTP) | RDS, Aurora |
| Key-value or document access, massive scale, flexible schema | Non-relational (NoSQL) | DynamoDB, DocumentDB, Keyspaces |
| Complex reporting, aggregations over huge datasets | Analytical (OLAP) | Redshift |
| Read latency reduction, session/cache | In-memory | ElastiCache, DAX |
| Specialized shape (graph, ledger, time-series) | Purpose-built | Neptune, QLDB, Timestream |
The single most useful distinction to internalize is OLTP vs. OLAP. OLTP (Online Transaction Processing) means many small, fast reads and writes — an e-commerce checkout, a banking transaction. OLAP (Online Analytical Processing) means a few enormous, complex queries scanning billions of rows — a sales dashboard, a data warehouse. If a question mentions “reporting,” “analytics,” “business intelligence,” or “aggregating years of data,” it’s steering you toward Redshift, not RDS.
Amazon RDS: Managed Relational Databases
Amazon RDS runs managed relational engines: MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. AWS handles patching, backups, and failover; you keep the SQL and the schema you already know. RDS is the default answer whenever a workload needs a traditional relational database and doesn’t specifically call for Aurora’s scale.
The two RDS features the exam tests most are also the two most commonly confused, so we’ll be precise.
Multi-AZ vs. Read Replicas — the classic trap
These sound similar and solve completely different problems.
| Multi-AZ | Read Replica | |
|---|---|---|
| Purpose | High availability / failover | Scale read traffic |
| Replication | Synchronous | Asynchronous |
| Standby usable? | No — standby is passive until failover | Yes — actively serves reads |
| Failover | Automatic, DNS flips to standby | Manual promotion to standalone DB |
| Cross-Region? | No (same Region, different AZ) | Yes — read replicas can be cross-Region |
The exam phrasing is your cue. “Withstand an AZ failure,” “high availability,” “automatic failover” → Multi-AZ. “Offload reporting,” “scale read-heavy traffic,” “reduce load on the primary” → read replicas. And they compose: you can have a Multi-AZ primary and read replicas at the same time. A question that wants both HA and read scaling wants both features — not one or the other.
# Create a Multi-AZ MySQL instance (high availability)
aws rds create-db-instance \
--db-instance-identifier app-prod \
--engine mysql \
--db-instance-class db.r6g.large \
--multi-az \
--allocated-storage 100 \
--storage-encrypted \
--master-username admin \
--manage-master-user-password
# Add a read replica to scale reads
aws rds create-db-instance-read-replica \
--db-instance-identifier app-prod-replica \
--source-db-instance-identifier app-prodRDS features worth knowing
- Automated backups & snapshots: point-in-time recovery within the retention window (up to 35 days); manual snapshots persist until you delete them.
- Storage autoscaling: RDS grows storage automatically as you approach the limit.
- RDS Proxy: a managed connection pool that sits in front of RDS/Aurora. The exam answer for “too many database connections from Lambda” or “improve failover times for a serverless app” is RDS Proxy.
- Encryption at rest with KMS (must be enabled at creation) and in transit with TLS — the same encryption discipline you’ll recognize from designing secure architectures.
Amazon Aurora: RDS, Rearchitected for the Cloud
Aurora is AWS’s cloud-native relational engine, compatible with MySQL and PostgreSQL. It keeps the relational model but replaces the storage layer with a distributed, self-healing design: your data is stored as six copies across three Availability Zones, and Aurora tolerates the loss of an entire AZ without data loss.
When do you pick Aurora over plain RDS? When the question emphasizes any of these:
- Higher performance and throughput than standard MySQL/PostgreSQL (AWS markets several times the throughput).
- Up to 15 low-latency read replicas sharing the same storage volume — far more read scaling than RDS.
- Aurora Global Database: replicates to secondary Regions with typical latency under a second, for cross-Region disaster recovery and low-latency global reads. This is the exam answer for “relational database with a Region-level DR requirement and fast global reads.”
- Aurora Serverless v2: capacity scales automatically with load, ideal for variable or unpredictable relational workloads — pair it mentally with cost-optimized architectures.
- Backtrack (Aurora MySQL): rewind the database to a prior point in time without restoring a snapshot.
Aurora also exposes a cluster (writer) endpoint and a reader endpoint that load-balances across replicas. A scenario that wants the application to automatically spread reads across replicas points to the reader endpoint.
| Requirement | RDS or Aurora? |
|---|---|
| Standard MySQL app, moderate scale, lowest management | RDS |
| Need Oracle or SQL Server | RDS (Aurora is MySQL/PostgreSQL only) |
| Relational + cross-Region DR under a second | Aurora Global Database |
| Up to 15 read replicas, high throughput | Aurora |
| Variable/spiky relational load, pay for what you use | Aurora Serverless v2 |
Amazon DynamoDB: Serverless NoSQL at Any Scale
DynamoDB is a fully managed, serverless key-value and document database delivering single-digit-millisecond latency at effectively unlimited scale. There are no servers to manage and no instances to size — you work with tables, items, and a partition (hash) key. DynamoDB is the exam’s go-to for “massive scale,” “serverless,” “flexible schema,” “predictable low latency,” and “no operational overhead.”
Capacity modes and scaling
- On-demand: pay per request, scales instantly with no capacity planning — the answer for unpredictable or spiky traffic and new apps with unknown load.
- Provisioned: you set read/write capacity units (with auto-scaling optional) — cheaper for steady, predictable workloads.
DynamoDB features the exam tests
| Feature | What it does | Exam trigger |
|---|---|---|
| DAX | In-memory cache for DynamoDB | ”Microsecond latency,” “read-heavy DynamoDB” |
| Global Tables | Multi-Region, active-active replication | ”Multi-Region,” “low-latency global writes” |
| Streams | Change data capture feed | ”Trigger a Lambda on item change” |
| TTL | Auto-expire items by timestamp | ”Automatically delete old sessions/records” |
DAX vs. ElastiCache is a favorite trap: DAX is purpose-built to cache DynamoDB and speaks the DynamoDB API, dropping read latency from milliseconds to microseconds. ElastiCache is a general-purpose cache you place in front of any database. If the backing store is DynamoDB and the ask is microsecond reads, the answer is DAX.
# On-demand DynamoDB table with a partition key
aws dynamodb create-table \
--table-name Sessions \
--attribute-definitions AttributeName=sessionId,AttributeType=S \
--key-schema AttributeName=sessionId,KeyType=HASH \
--billing-mode PAY_PER_REQUEST \
--sse-specification Enabled=trueGood partition-key design (high cardinality, even access distribution) is what keeps DynamoDB fast — a theme explored further in the Developer Associate DynamoDB guide if you want to go deeper than SAA requires.
Amazon ElastiCache: In-Memory Speed
ElastiCache provides managed in-memory data stores in two flavors, and the exam expects you to choose between them.
| ElastiCache for Redis | ElastiCache for Memcached | |
|---|---|---|
| Data structures | Rich (lists, sets, sorted sets, pub/sub) | Simple key-value only |
| Persistence & backup | Yes | No |
| Replication / HA | Yes (Multi-AZ, replicas) | No |
| Multi-threaded | No | Yes (scales with cores) |
| Use case | Leaderboards, sessions, HA cache | Simple, horizontally scaled cache |
The heuristic: Redis when you need durability, replication, high availability, or advanced data structures; Memcached when you need a simple, multi-threaded cache you can scale out and don’t mind losing on restart. ElastiCache’s classic SAA role is the cache-aside pattern — reduce read load and latency on an RDS/Aurora database by serving hot data from memory. When a read-heavy relational workload is straining the database and you want to reduce latency, ElastiCache is the answer; this ties directly into high-performing architectures.
Amazon Redshift: The Data Warehouse
Redshift is a petabyte-scale, columnar data warehouse for OLAP — complex analytical queries over huge datasets. It is not an OLTP database and should never be the answer for transactional, low-latency single-row lookups. Reach for Redshift when the scenario mentions:
- Business intelligence, dashboards, or reporting over large historical datasets
- Aggregations, joins, and window functions across billions of rows
- Redshift Spectrum, which queries data directly in S3 without loading it first
If a question describes an operational app doing frequent small writes, Redshift is a distractor. If it describes analysts running heavy queries over a warehouse of historical data, Redshift is the answer.
The Purpose-Built Engines
The SAA-C03 exam includes a handful of specialized databases. You don’t need deep expertise — just enough to recognize the one-line signal that selects each.
| Service | Data model | The signal that selects it |
|---|---|---|
| Amazon Neptune | Graph | ”Relationships,” “social network,” “fraud graph,” “recommendations” |
| Amazon QLDB | Ledger | ”Immutable,” “cryptographically verifiable transaction history” |
| Amazon Timestream | Time-series | ”IoT sensor data,” “metrics over time” |
| Amazon DocumentDB | Document | ”MongoDB-compatible” |
| Amazon Keyspaces | Wide-column | ”Cassandra-compatible” |
| Amazon MemoryDB | In-memory + durable | ”Redis-compatible primary database with durability” |
These are pattern-match questions. See “graph” or “relationships between entities,” choose Neptune. See “immutable, verifiable ledger,” choose QLDB. Don’t overthink them.
The Decision Framework
Here’s the mental flowchart to run in the exam. Read the scenario, then walk down:
- Is it analytics/reporting over huge datasets (OLAP)? → Redshift.
- Is it a specialized shape — graph, ledger, time-series? → Neptune / QLDB / Timestream.
- Does it need a relational model / SQL / joins / transactions?
- Need Oracle/SQL Server, or simplest managed relational → RDS.
- Need high throughput, 15 read replicas, cross-Region DR, or serverless relational → Aurora.
- Need HA within a Region → add Multi-AZ. Need read scaling → add read replicas.
- Is it key-value/document at massive scale, serverless, flexible schema? → DynamoDB (add DAX for microsecond reads, Global Tables for multi-Region).
- Is it about reducing read latency / caching / sessions? → ElastiCache (Redis for HA/persistence, Memcached for simple scale-out).
Run that sequence and the vast majority of SAA-C03 database questions collapse to a single answer.
Cross-Cutting Concerns the Exam Also Checks
Whichever database you pick, the exam weaves in these recurring themes:
- Encryption: at rest with KMS (enable at creation for RDS/Aurora), in transit with TLS. DynamoDB encrypts at rest by default.
- Backups & DR: RDS automated backups + snapshots; Aurora continuous backup to S3 and Global Database for cross-Region DR; DynamoDB point-in-time recovery and on-demand backups.
- Networking: put databases in private subnets, control access with security groups, and reach them privately — the same design discipline covered in VPC concepts for SAA-C03.
- Cost: on-demand vs. provisioned (DynamoDB), Serverless vs. provisioned (Aurora), Reserved Instances for steady RDS — connect this with cost-optimized architectures.
Frequently Asked Questions
What’s the difference between Multi-AZ and a read replica in RDS?
Multi-AZ is for high availability: a synchronous standby in another AZ that automatically takes over on failure, but never serves traffic otherwise. A read replica is for scaling reads: an asynchronous copy that actively serves read queries and can be promoted manually. HA questions want Multi-AZ; read-scaling questions want read replicas. They can be used together.
When should I choose DynamoDB over RDS or Aurora?
Choose DynamoDB when you need massive, elastic scale with predictable single-digit-millisecond latency, a flexible schema, and no server management — and your access pattern is key-value or document, not complex joins and transactions. Choose RDS/Aurora when you need the relational model, SQL joins, and strong transactional consistency across tables.
What’s the difference between DAX and ElastiCache?
DAX is an in-memory cache purpose-built for DynamoDB — it speaks the DynamoDB API and delivers microsecond reads with no application rewrite. ElastiCache is a general-purpose in-memory store (Redis or Memcached) you place in front of any database, most often to cache reads from RDS/Aurora. If the backing store is DynamoDB, the answer is DAX.
Is Redshift a good choice for a transactional application?
No. Redshift is an OLAP data warehouse optimized for large analytical queries, not the frequent small reads and writes of a transactional (OLTP) app. For OLTP, use RDS, Aurora, or DynamoDB. Redshift appears as a distractor in transactional scenarios — and as the right answer in reporting/analytics scenarios.
How do I get a relational database with cross-Region disaster recovery?
Use Aurora Global Database, which replicates to secondary Regions with typical latency under a second, enabling fast cross-Region failover and low-latency local reads. RDS read replicas can also be cross-Region, but Aurora Global Database is the purpose-built answer for relational Region-level DR.
Do I need to memorize every purpose-built database for SAA-C03?
You don’t need deep expertise, but you should recognize the one-line signal for each: Neptune for graphs, QLDB for immutable ledgers, Timestream for time-series, DocumentDB for MongoDB compatibility, Keyspaces for Cassandra. These are pattern-match questions worth easy points.
Conclusion and Next Steps
AWS database questions look intimidating because of the sheer number of services, but they reward a disciplined decision process: classify the workload (OLTP, OLAP, key-value, in-memory, specialized), then match it to the purpose-built service. Nail the recurring distinctions — Multi-AZ vs. read replica, DAX vs. ElastiCache, RDS vs. Aurora, Aurora Global Database for relational DR — and these become some of the most reliable points on the exam.
The fastest way to turn this framework into exam-day reflexes is realistic practice. Sailor.sh’s AWS Certified Solutions Architect Associate (SAA-C03) Mock Exam Bundle gives you exam-style scenario questions that mirror the real format and difficulty — including the database-selection trade-offs covered here — with detailed explanations that surface the exact distinctions the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with the full Solutions Architect Associate guide, then round out your architecture knowledge with resilient architectures, high-performing architectures, storage services, and designing secure architectures.