Overview
Pick RDS Postgres for most workloads. It is standard Postgres with automated backups, Multi-AZ failover, and patch management. You get a known quantity at a predictable cost. Pick Aurora Postgres when the workload requires sub-30-second failover (Aurora fails over in roughly 30 seconds versus RDS Multi-AZ at 60-120 seconds), up to 15 low-latency read replicas, or when the storage auto-scaling model (Aurora grows in 10 GB chunks up to 128 TB; RDS requires manual storage scaling) removes operational burden. The Aurora price premium is real: Aurora Postgres costs roughly 20 percent more per instance hour than equivalent RDS, plus Aurora charges for I/O operations on Standard (non-Serverless v2) instances. See postgres for the Postgres rule set and postgres-replication for replication patterns.
When RDS Postgres wins
RDS Postgres is the right choice for the majority of AWS-hosted Postgres workloads.
- Standard Postgres: RDS runs unmodified Postgres 13-16+. All extensions, wire protocol behavior, and query planner semantics are identical to on-premises Postgres. Aurora has minor behavioral differences (see below).
- Cost: RDS is roughly 20 percent cheaper per instance hour than equivalent Aurora instances. For small-to-medium workloads (under 1 TB, single writer, a few read replicas), the cost difference adds up.
- No I/O tax: RDS charges for the provisioned IOPS or gp3 volume; there is no per-I/O surcharge on top of storage. Aurora Standard charges $0.20 per million I/O operations on top of storage cost.
- Aurora Serverless v2 breakeven: Aurora Serverless v2 is cost-effective only when the workload has large idle periods (nights, weekends). For steady-state traffic, provisioned RDS is cheaper.
- Logical replication: RDS Postgres supports
wal_level = logical, which enables change-data capture (CDC) with Debezium or pglogical. Aurora’s logical replication support is available but has historically had more caveats. - Upgrade path: RDS major version upgrades (e.g., Postgres 15 to 16) are straightforward. Aurora major version upgrades require more care due to the custom storage layer.
When Aurora wins
Aurora is the right choice when availability, failover speed, or read scale are the hard requirements.
- Failover speed: Aurora fails over to a replica in roughly 20-30 seconds by promoting an existing replica. RDS Multi-AZ takes 60-120 seconds, involves a DNS change, and requires a cold start on the standby. For payment-critical or always-on services, the difference is meaningful.
- Up to 15 read replicas: all replicas share the same underlying distributed storage volume; replication lag is typically under 100 ms. RDS supports up to 5 read replicas with logical replication lag that grows under write pressure.
- Storage auto-scaling: Aurora storage grows automatically in 10 GB chunks; you never provision storage or handle a “disk full” incident. RDS requires enabling storage autoscaling explicitly and it is less fine-grained.
- Aurora Global Database: replicate across AWS regions with replication lag under 1 second; useful for multi-region active-passive failover.
- Aurora Serverless v2: scales ACUs (Aurora Capacity Units) up and down per second. For workloads with unpredictable or spiky traffic, Serverless v2 can cost less than a provisioned instance that is over-provisioned for peak.
- Backtrack: Aurora Postgres supports rewinding the cluster to a point in time without restoring from a snapshot; useful for recovering from accidental bulk deletes.
Trade-offs at a glance
| Dimension | RDS Postgres | Aurora Postgres |
|---|---|---|
| Price per instance hour | Lower (baseline) | ~20% higher |
| I/O cost | Provisioned volume; no per-I/O charge | Per-million I/O operations (Standard) |
| Failover time | 60-120 seconds (Multi-AZ) | 20-30 seconds |
| Read replicas | Up to 5; logical replication lag | Up to 15; shared storage; <100 ms lag |
| Storage scaling | Manual or auto-scaling (coarse) | Automatic; 10 GB increments to 128 TB |
| Postgres compatibility | Full standard Postgres | Minor behavioral differences |
| Logical replication | Supported | Supported; more caveats historically |
| Global replication | Not available | Aurora Global Database (<1 s RPO) |
| Backtrack | Not available | Available; in-place point-in-time rewind |
| Serverless option | Not available | Aurora Serverless v2 |
Migration cost
RDS to Aurora is an AWS-native migration; it does not require a data dump.
- RDS to Aurora: use the “Migrate snapshot to Aurora” feature in the AWS console or CLI. Restore the latest RDS snapshot as an Aurora cluster. Application connection strings change (new endpoint); Postgres client behavior is unchanged for most workloads. Plan one engineer-day plus a verification period for connection pooling and query behavior.
- Aurora to RDS: export an Aurora snapshot, restore as RDS. The reverse migration is less common and takes the same effort.
- Behavioral differences to verify: Aurora uses a custom storage layer and may differ in WAL behavior,
pg_statviews, and some VACUUM internals. Test VACUUM and autovacuum behavior, logical replication slots, and extension compatibility before promotion.
Recommendation
- New application with steady traffic under 500 GB: RDS Postgres Multi-AZ. Lower cost, standard behavior.
- Payment-critical service requiring fast failover: Aurora Postgres with at least one read replica. The 30-second failover versus 2-minute failover is worth the premium.
- High read fan-out (reporting, dashboards, analytics reads): Aurora with read replicas on the read endpoint. See read-replica.
- Unpredictable traffic spikes (B2C, scheduled jobs): Aurora Serverless v2. Scale to zero or near-zero during idle.
- Multi-region active-passive disaster recovery: Aurora Global Database.
- Data warehouse or analytical queries over millions of rows: neither; evaluate Amazon Redshift or a columnar store. See dynamodb-vs-postgres for the NoSQL alternative framing.