AWS RDS for PostgreSQL and Aurora

AWS offers two managed paths for PostgreSQL workloads, and they are not the same product. Amazon RDS for PostgreSQL runs the community engine as a managed instance. Aurora PostgreSQL-Compatible is a PostgreSQL-compatible engine on AWS-built distributed storage, managed as a cluster rather than a server. Drivers and most SQL work on both; parameters, extensions, failover, and billing do not behave identically. For the cross-provider view, see the cloud service map.

When each one fits

RDS for PostgreSQL is the default choice when:

• you want behavior as close to community PostgreSQL as a managed service allows;
• one primary with an optional Multi-AZ standby and read replicas meets your availability target;
• storage stays comfortably below the 64 TiB ceiling and you prefer provisioned, predictable sizing.

Aurora PostgreSQL-Compatible earns its price when:

• you need faster failover and read scaling across up to 15 Aurora Replicas that share one cluster volume;
• storage should grow automatically in 10 GiB increments instead of being provisioned, up to 256 TiB;
• you accept an engine with its own release cadence, versioning scheme, and extension allowlist.

This is not a ranking. Both are managed services without host access, and the right answer depends on your measured failover, connection, and cost requirements.

RDS and Aurora side by side

Differences to accept

• max_connections is computed differently on Aurora. The default is LEAST({DBInstanceClassMemory/9531392}, 5000) — a 16 GiB instance lands around 1,800 connections, and the cap is 5,000 regardless of instance size. High-concurrency applications need RDS Proxy or PgBouncer in front of either service; see the Aurora parameter reference.
• Extension availability is a per-engine allowlist. Extensions that work on RDS, such as pg_repack, may be missing or version-pinned on Aurora. Diff your pg_extension list against the Aurora support matrix before migrating, not after.
• Aurora is managed as a cluster. Some parameters apply cluster-wide, some system views and wait events differ from community PostgreSQL, and storage is billed by consumption plus I/O requests rather than provisioned capacity.
• Neither service gives host or superuser access. rds_superuser is a reduced role; anything requiring OS access, arbitrary shared_preload_libraries, or untrusted languages is out of scope on both.

Validate before production

1. Diff installed extensions and their exact versions against the target engine's allowlist.
2. Run a real failover drill and time the application's reconnection behavior, not just the DNS flip.
3. Size the connection budget from max_connections, then decide on RDS Proxy or PgBouncer and its pooling mode.
4. Perform a PITR restore into a fresh instance or cluster and measure actual RPO/RTO.
5. Model cost with realistic I/O — Aurora bills I/O requests separately, which surprises workloads migrating from provisioned RDS storage.
6. Export once with pg_dump or snapshot export and restore into an independent PostgreSQL environment as an exit-path test.

For connection pooling, backup drills, and monitoring baselines that apply regardless of provider, see the production stack guide. If you only need a development or evaluation database, the free PostgreSQL guide covers zero-cost alternatives.