---
title: "Aurora vs RDS Postgres"
slug: "aurora-vs-rds-postgres"
category: "comparisons"
tags: ["comparisons", "aurora", "rds", "postgres", "aws", "database"]
status: "stable"
last_updated: 2026-05-14
summary: "Pick RDS Postgres for cost and compatibility; pick Aurora Postgres for high availability, fast failover, and read scale-out at a higher price."
related: ["[[backend/postgres]]", "[[backend/postgres-replication]]", "[[comparisons/dynamodb-vs-postgres]]", "[[comparisons/mongodb-vs-postgres]]", "[[backend/postgres-indexes]]", "[[comparisons/aws-vs-cloudflare]]", "[[glossary/read-replica]]"]
---

## 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 [[backend/postgres]] for the Postgres rule set and [[backend/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_stat` views, 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 [[glossary/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 [[comparisons/dynamodb-vs-postgres]] for the NoSQL alternative framing.

## Related

- [[backend/postgres]]
- [[backend/postgres-replication]]
- [[comparisons/dynamodb-vs-postgres]]
- [[comparisons/mongodb-vs-postgres]]
- [[backend/postgres-indexes]]
- [[comparisons/aws-vs-cloudflare]]
- [[glossary/read-replica]]