Aurora vs RDS: PostgreSQL and MySQL on AWS Compared

Aurora vs RDS is the first database decision most teams make on AWS, and it applies to both engines. Amazon RDS runs community PostgreSQL and MySQL on EBS volumes. Amazon Aurora keeps the PostgreSQL or MySQL front end and replaces the storage layer with a shared, distributed cluster volume. That one difference drives almost every row in the table below.

The short verdict: RDS is the better default for a single production database with steady load, a modest read volume, and a cost-sensitive budget. Aurora is worth the premium when you need several read replicas, failover in well under a minute, cross-Region disaster recovery, fast clones of production data, or storage that grows and shrinks without planning.

This comparison covers Aurora vs RDS for PostgreSQL and Aurora MySQL vs RDS for MySQL together, calling out the places where the engines differ. If you are only evaluating Aurora PostgreSQL, our Aurora PostgreSQL guide covers its features and costs in more detail.

The architectural difference

RDS stores data on Amazon EBS volumes attached to the database instance. You choose a volume type and size, and RDS runs the stock engine against it. A standby or read replica is another instance with another volume, kept current by replication.

Aurora stores data in a cluster volume that spans three Availability Zones in one Region. When the writer commits, Aurora synchronously replicates the change to six storage nodes across those zones. Every instance in the cluster, writer and readers, reads from the same volume.

AWS describes the consequence directly: adding an Aurora instance is fast "because Aurora doesn't make a new copy of the table data." The new instance attaches to the volume that already holds your data. Removing an instance deletes no data. Only deleting the cluster does.

The amount of replication is also independent of how many instances you run. A single-instance Aurora cluster still has six copies of its data across three zones. What it lacks is a second instance to fail over to, which matters in the failover section below.

Storage: allocated vs used

RDS asks you to allocate storage up front. For PostgreSQL and MySQL the limit is 64 TiB per instance, and you pay for the allocated amount whether you fill it or not. Storage autoscaling can grow the volume when free space runs low, but growth only goes one way. The RDS docs are explicit: you increase allocated space by at least 10%, and "You can't deallocate space."

Performance is tied to that volume. On gp3, RDS for PostgreSQL and MySQL provides a baseline of 3,000 IOPS below 400 GiB and 12,000 IOPS at or above it, because larger volumes are striped across four EBS volumes. You can pay for more IOPS and throughput above the baseline, or move to io2 Block Express for up to 256,000 provisioned IOPS.

Aurora has no storage size to pick. The cluster volume grows as data arrives and, on current versions, shrinks when you drop or truncate tables. Its maximum depends on the engine version: 256 TiB for Aurora PostgreSQL 17.5 and higher (plus 16.9 and 15.13 onward) and Aurora MySQL 3.10 and higher, and 128 TiB for earlier versions. You are billed for the space you use, and AWS states you "only pay for one copy of the data" despite the six physical copies.

For a database that bloats and gets cleaned up, or one whose growth is hard to forecast, Aurora removes a capacity-planning task. For a database whose size is stable and known, RDS storage is simpler to reason about and usually cheaper.

Replication and read replicas

Both services allow up to 15 read replicas. They work in different ways.

An RDS read replica is a separate instance with its own storage, kept current with the engine's native asynchronous replication (streaming replication for PostgreSQL, binlog replication for MySQL). Each replica replays every write, and each one bills for its own storage. Replica lag depends on write volume and on how busy the replica is.

An Aurora Replica reads the same cluster volume as the writer. It does not replay changes into a private copy of the data, so adding one costs an instance and no extra storage. AWS says Aurora replica lag "is usually much less than 100 milliseconds," and increases during heavy write periods. A reader endpoint spreads read connections across all replicas.

If your application sends a large share of traffic to read replicas, or you expect to add and remove readers as load changes, Aurora's model is cheaper per replica and faster to scale. If one replica for reporting is all you need, the RDS model works fine.

High availability and failover

RDS offers two Multi-AZ options, and it is worth knowing both.

A Multi-AZ DB instance deployment keeps a synchronous standby in a second zone. The standby cannot serve reads. You pay for it to sit ready, and AWS notes that synchronous replication can raise write and commit latency. Failover times are "typically 60–120 seconds," longer with large transactions or lengthy recovery.

A Multi-AZ DB cluster deployment runs a writer and two readable standbys in three zones with semisynchronous replication. Failover is "typically under 35 seconds," and the standbys serve read traffic. It is supported only on specific instance classes, such as db.r6gd and db.m6gd. Despite the name, AWS points out that Multi-AZ DB clusters "aren't the same as Aurora DB clusters."

In Aurora, any replica is a failover target. You set a promotion priority from 0 to 15 on each one. When the writer fails, AWS says "service is typically restored in less than 60 seconds, and often less than 30 seconds." The cluster endpoint always points to the current writer, so applications reconnect to the same hostname.

One trap: a single-instance Aurora cluster has durable storage but nothing to promote. If that instance fails, Aurora recreates it, which "typically takes less than 10 minutes." Aurora's failover numbers assume you run at least one replica in another zone, and that replica costs a full instance.

For cross-Region recovery, Aurora Global Database replicates from a primary Region to up to 10 read-only secondary Regions through the storage layer, "with latency typically under a second." It supports planned switchovers without data loss and managed failover after a Regional outage. RDS handles the same need with cross-Region read replicas that you promote.

Aurora-only features

A few features exist because of Aurora's storage design and have no RDS equivalent.

• Fast clones. Aurora cloning creates a new cluster that shares data pages with the source using copy-on-write. Storage is only allocated as either side changes pages. A clone of a large production database for testing a migration costs little until the data diverges. On RDS, the equivalent is restoring a snapshot, which copies all the data.
• Backtrack (Aurora MySQL only). Backtrack rewinds a cluster to an earlier time, up to 72 hours back, without restoring a backup. It has to be enabled when you create or restore the cluster, and it is not available for Aurora PostgreSQL.
• Serverless capacity. Aurora Serverless v2 scales compute in fine-grained capacity units inside a normal Aurora cluster. We compare it with Neon in Neon vs Aurora Serverless.
• Global Database, covered above.

RDS has its own advantages here. It supports more engines (MariaDB, Oracle, SQL Server, and Db2 alongside PostgreSQL and MySQL), and it gives you direct control over storage type, IOPS, and throughput.

DB Pro

Work With Your Databases Like A Pro

Query, explore, and manage your databases with a beautiful desktop app and built-in AI.

Download Now

Aurora PostgreSQL vs RDS PostgreSQL

RDS for PostgreSQL runs the community engine. Aurora PostgreSQL is PostgreSQL-compatible: the SQL, wire protocol, drivers, and most extensions behave the same, but the storage and recovery code underneath is AWS's.

The practical difference for most teams is version timing. RDS for PostgreSQL made PostgreSQL 18 generally available in November 2025. Aurora PostgreSQL added PostgreSQL 18 in June 2026. If you want a new major version soon after release, RDS gets there first.

Extension support also differs between the two services and between versions. Before migrating, list what you use and check it against the target's supported extension list:

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

If you are unsure which service a connection string points to, Aurora PostgreSQL provides an aurora_version() function. On community PostgreSQL 18, including RDS, the same call fails:

postgres=# SELECT aurora_version();
ERROR:  function aurora_version() does not exist
LINE 1: SELECT aurora_version();
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

Aurora MySQL vs RDS MySQL

The "aurora vs mysql" question usually means Aurora MySQL against RDS for MySQL, which runs MySQL Community Edition. The same version-timing pattern applies. RDS for MySQL has supported MySQL 8.4 LTS since late 2024. Aurora MySQL 8.4 became generally available in May 2026, and it switched to version numbers that match community MySQL.

Aurora MySQL supports only the InnoDB storage engine for tables. Any MyISAM tables must be converted before you migrate. This query finds them:

SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
  AND engine <> 'InnoDB'
  AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');

Run against a MySQL 8.4 test database with one MyISAM table, it returns:

+--------------+------------+--------+
| TABLE_SCHEMA | TABLE_NAME | ENGINE |
+--------------+------------+--------+
| shop         | sessions   | MyISAM |
+--------------+------------+--------+

Convert each result with ALTER TABLE shop.sessions ENGINE=InnoDB; before the move.

Aurora MySQL exposes its version through @@aurora_version. On community MySQL 8.4 the variable does not exist:

ERROR 1193 (HY000) at line 1: Unknown system variable 'aurora_version'

Backtrack and parallel query are Aurora MySQL features with no RDS for MySQL equivalent. On the RDS side, Multi-AZ DB clusters and a wider choice of storage performance settings are the main reasons MySQL teams stay.

For the engine choice itself rather than the hosting choice, see PostgreSQL vs MySQL.

Pricing models compared

Both services bill instance hours, and both offer reserved pricing for steady workloads. The rest of the bill is shaped differently, which is why the same workload can cost more on either one. Check the Aurora pricing page and the AWS Pricing Calculator for current rates in your Region.

RDS charges for:

• Each instance, including a Multi-AZ standby that serves no reads
• Allocated storage per GB-month
• Provisioned IOPS and throughput above the gp3 baseline, or all provisioned IOPS on io2
• Backup storage beyond the free allowance

Aurora charges for:

• Each instance in the cluster, writer and readers
• Storage used per GB-month, counting one copy of the data
• I/O requests, on the Aurora Standard configuration only
• Backup storage beyond the free allowance, plus extras such as Global Database replication and Backtrack change records

Aurora has two storage configurations. Aurora Standard charges per million I/O requests and has lower instance and storage rates. Aurora I/O-Optimized removes I/O charges in exchange for higher instance and storage rates. AWS's guidance is to choose I/O-Optimized when I/O is 25% or more of your Aurora spend. You can switch from Standard to I/O-Optimized once every 30 days, and back to Standard at any time. The switch involves no downtime on non-NVMe instances, but NVMe-based instances need an engine restart.

What this means in practice:

• A single instance with steady load and moderate I/O usually costs less on RDS.
• High availability narrows the gap. An RDS Multi-AZ standby is a paid instance that serves no reads, while an Aurora replica does double duty as failover target and reader.
• Unpredictable I/O on Aurora Standard can make bills hard to forecast. I/O-Optimized fixes that at a higher base rate.
• Several read replicas favour Aurora, because each RDS replica also pays for its own copy of the storage.

Price your real workload in both configurations rather than trusting a rule of thumb. The Neon vs RDS comparison covers a third option if idle time is a large part of your usage.

Migrating from RDS to Aurora

The lowest-risk path runs through replication. You can create an Aurora read replica of an RDS for PostgreSQL or RDS for MySQL instance, let it catch up, then promote it to a standalone Aurora cluster during a short cutover. Snapshot restore and dump-and-load also work.

Before cutting over:

1. Check extensions (PostgreSQL) or storage engines (MySQL) with the queries above.
2. Confirm the target Aurora version supports your current major version.
3. Point the application at the cluster endpoint for writes and the reader endpoint for reads.
4. Run the real workload against a clone and compare query plans. Tools such as a PostgreSQL client or MySQL client make it easy to run the same queries against both endpoints side by side.

Going the other way, from Aurora back to RDS, means a logical migration with dump and restore or native logical replication, because Aurora's storage format is not EBS.

When to choose RDS

• You run one primary database with steady, predictable load.
• You need a new PostgreSQL or MySQL major version soon after AWS supports it.
• Your storage size is stable and your I/O is moderate.
• One standby for availability and perhaps one replica for reporting covers your needs.
• You want direct control over storage type, IOPS, and throughput.
• You need MariaDB, Oracle, SQL Server, or Db2, which Aurora does not offer.

When to choose Aurora

• You rely on several read replicas or want to add and remove them quickly.
• You need failover measured in seconds, and you will run at least one replica in another zone.
• You need cross-Region disaster recovery with sub-second replication lag.
• Your storage grows unpredictably, or you regularly delete large amounts of data.
• Fast copy-on-write clones of production would change how you test migrations.
• Your I/O is heavy enough that I/O-Optimized gives you a predictable bill.

The verdict

Start on RDS unless you can name the Aurora feature you need. Community PostgreSQL or MySQL on RDS is cheaper for a typical single-writer workload, gets new versions first, and hides fewer details behind AWS-specific storage.

Move to Aurora when replicas, failover time, Global Database, or clones become requirements rather than nice-to-haves. The two services share engines, drivers, and SQL, so the move is a hosting change, not a rewrite. For a deeper look at Aurora on the PostgreSQL side, read our Aurora PostgreSQL guide.