RDS Engines and Instance Classes

Amazon RDS supports six database engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora. Each engine is a fully managed version of the open-source or commercial database you already know. AWS handles patching, backups, and failover so you can focus on your application logic.

Choosing the right engine depends on your existing application requirements, licensing costs, and the features each engine provides. Aurora is AWS's cloud-native option built for performance and availability.

MySQL is the world's most popular open-source relational database and is a natural fit for web applications and CMSs. PostgreSQL offers advanced SQL compliance, strong JSONB support, and powerful extension ecosystem, making it popular for analytics and geospatial workloads.

Both engines on RDS support automated backups, Multi-AZ deployments, and Read Replicas. PostgreSQL Read Replicas can span across regions, while MySQL supports up to 15 cross-region replicas with Aurora MySQL.

MariaDB is a community-developed fork of MySQL, fully compatible at the wire-protocol level with MySQL clients. It offers additional storage engines, better performance in some workloads, and an open development model with no proprietary features.

On RDS, MariaDB is a drop-in replacement for MySQL if you want to avoid Oracle's MySQL licensing or prefer the community fork. It supports the same automated backup, Multi-AZ, and Read Replica features as MySQL.

Oracle Database on RDS supports both License Included (LI) and Bring Your Own License (BYOL) models. LI bundles the Oracle SE2 license into the hourly rate, while BYOL lets you use your existing Enterprise Edition license for features like partitioning and Advanced Security.

Microsoft SQL Server on RDS similarly offers LI editions (Express, Web, Standard, Enterprise) and BYOL. Both engines support Multi-AZ with Synchronous Mirroring but do not support Read Replicas the same way as open-source engines.

Amazon Aurora is a cloud-native relational database compatible with both MySQL and PostgreSQL. Aurora delivers up to 5x the throughput of MySQL and 3x the throughput of PostgreSQL on the same hardware by using a distributed storage layer that automatically replicates data six ways across three Availability Zones.

Aurora's storage grows automatically in 10 GB increments up to 128 TiB, eliminating manual storage provisioning. The separation of compute and storage also allows Aurora Serverless to scale capacity up and down automatically.

RDS instance classes follow the same naming convention as EC2 but are prefixed with db. instead of just the family letter. The main families are:

• db.t — Burstable performance, cost-effective for dev/test (e.g., db.t3.micro, db.t4g.small)
• db.m — General purpose, balanced CPU/memory (e.g., db.m6g.large)
• db.r — Memory-optimised for large caches and in-memory tables (e.g., db.r6g.xlarge)
• db.x — Extreme memory for Oracle and SQL Server with SAP workloads

Choose db.t for development, db.m for typical production, and db.r for databases with large working sets.

Selecting an RDS instance class requires profiling your workload's CPU utilisation, memory consumption, IOPS needs, and network bandwidth. AWS Compute Optimizer and the RDS Performance Insights tool help identify if your current instance is over- or under-provisioned.

A common pattern is to start with a db.t3 for prototyping, move to db.m6g when the load becomes steady, and graduate to db.r6g when queries benefit from a larger buffer pool. Graviton2-based instances (db.m6g, db.r6g) typically offer up to 35% better price-performance than x86 equivalents.

RDS offers three storage types that map to EBS volumes behind the scenes:

• gp2 / gp3 — General Purpose SSD; gp3 lets you independently provision IOPS and throughput without paying for more storage
• io1 / io2 — Provisioned IOPS SSD for latency-sensitive OLTP databases requiring consistent sub-millisecond response
• st1 — Throughput Optimised HDD, available only for specific engines and test workloads

For most production RDS deployments, gp3 is the recommended default because it offers 3,000 IOPS at no extra cost and can be scaled independently of storage size.

RDS supports two scaling dimensions. Vertical scaling (instance class change) requires a brief downtime window unless Multi-AZ is enabled—with Multi-AZ the failover allows near-zero downtime during the resize. You can schedule the modification for the next maintenance window or apply it immediately.

Horizontal scaling is read-only: you add Read Replicas to distribute SELECT queries away from the primary. Read Replicas use asynchronous replication, so there is a small replication lag that your application must tolerate.

When choosing between Aurora and community MySQL/PostgreSQL, consider these trade-offs:

• Aurora: higher throughput, automatic 6-way replication, fast failover (~30 s), no manual storage management, higher per-hour cost
• MySQL/PostgreSQL: lower cost, broader community extensions, BYOL option, familiar operational tooling

For exam scenarios, Aurora is preferred when the question emphasises high availability, automatic storage growth, or performance close to commercial databases at open-source price. Community engines win when cost minimisation or feature parity with on-premises is the priority.

RDS separates minor version upgrades (e.g., MySQL 8.0.32 → 8.0.36) from major version upgrades (e.g., MySQL 5.7 → 8.0). Minor upgrades can be set to auto-apply during the maintenance window by enabling --auto-minor-version-upgrade. Major upgrades are manual and may require application compatibility testing.

Always test major version upgrades in a staging environment first. You can take a DB snapshot before the upgrade to roll back if problems arise. Aurora clusters support in-place major version upgrades with minimal disruption.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: RDS supports six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), instance classes map to workload profiles (db.t for dev/test, db.m for general, db.r for memory-intensive), and Aurora offers superior throughput and automatic storage scaling compared to community engines. Next up we explore Multi-AZ deployments and automated backups for high availability.