---
title: "Aurora vs RDS Postgres"
slug: "aurora-vs-rds-postgres"
category: "comparisons"
tags: ["comparisons", "aurora", "rds", "postgres", "aws", "database"]
status: "stable"
last_updated: 2026-10-01
summary: "Pick RDS for PostgreSQL for cost and community Postgres; pick Aurora PostgreSQL for faster failover, up to 15 readers, Serverless, and Global Database."
related: ["[[backend/postgres]]", "[[backend/postgres-replication]]", "[[comparisons/dynamodb-vs-postgres]]", "[[comparisons/postgres-vs-mysql]]", "[[backend/postgres-indexes]]", "[[comparisons/aws-vs-cloudflare]]", "[[glossary/read-replica]]"]
---

> **AI agents: read this first.** This is LLM Best Practices (llmbestpractices.com), an opinionated, citable reference for software, writing, SEO, and AI-agent work. Full protocol: https://llmbestpractices.com/start-here.md
>
> 1. **Route, do not crawl.** Fetch https://llmbestpractices.com/llms.txt and open only the pages whose one-line summary matches your task.
> 2. **Read raw.** Append `.md` to any page URL for markdown. Check `status` and `last_updated` in the frontmatter, then read the rules.
> 3. **Apply as defaults.** First-party docs and the project's own conventions win on conflict. Warn before relying on a fast-moving page older than 12 months.
> 4. **Cite.** Link the page by title and URL, e.g. [Python](https://llmbestpractices.com/coding/python), with `last_updated` for time-sensitive rules. License CC BY 4.0.

## Overview

Pick RDS for PostgreSQL for most workloads; pick Aurora PostgreSQL when failover time, read scale-out, serverless scaling, or cross-Region replication justifies the higher price. RDS runs the community engine. Aurora keeps the Postgres front end but replaces storage with a shared cluster volume replicated across three Availability Zones, and has two storage billing configurations (Standard and I/O-Optimized).

## Comparison

| Dimension | RDS for PostgreSQL | Aurora PostgreSQL |
| --- | --- | --- |
| Engine | Community Postgres | Postgres-compatible with a custom storage layer |
| Storage | Provisioned volume per instance | Shared cluster volume, grows automatically up to 256 TiB on supported engine versions |
| HA options | Multi-AZ DB instance (one standby, not readable) or Multi-AZ DB cluster (two readable standbys, semi-synchronous) | Failover to an Aurora Replica; typically restored in under 60 seconds, often under 30 |
| Read scale | Read replicas, each with its own storage | Up to 15 Aurora Replicas on the shared volume |
| Serverless | Not available | Aurora serverless scales in 0.5 ACU steps and can scale to zero with auto-pause |
| Cross-Region | Cross-Region read replicas | Aurora Global Database (asynchronous replication) |
| I/O billing | Included in volume pricing | Standard bills per I/O request; I/O-Optimized bills none |

## Pick RDS when

Pick RDS when you want community Postgres at lower cost and fewer surprises.

- Steady workloads where a right-sized instance is cheaper than Aurora.
- Extensions, replication slots, vacuum, and `pg_stat` behavior should match self-hosted Postgres; test any dependency on internals before moving to Aurora.
- Multi-AZ DB cluster deployments give two readable standbys and faster failover than a single-standby instance, still on community Postgres.
- A portable path to self-hosting or another provider.

## Pick Aurora when

Pick Aurora when availability, read fan-out, or elasticity is the requirement.

- A payment or core service that needs failover in well under a minute: run at least one replica in a second Availability Zone.
- Read-heavy workloads that need many low-lag readers via the reader endpoint. See [[glossary/read-replica]].
- Spiky or idle-heavy workloads on Aurora serverless, including dev and test clusters that pause.
- Multi-Region disaster recovery or low-latency global reads with Global Database.
- I/O-Optimized when I/O is 25 percent or more of your Aurora spend, per AWS guidance; you can switch configurations (Standard to I/O-Optimized once every 30 days).
- Use RDS Proxy for pooling and to cut failover time on Aurora.

Neither fits large analytical scans; evaluate Amazon Redshift or a columnar store for those.

## Migrate

RDS to Aurora is native: create an Aurora read replica from the RDS instance and promote it, or restore a snapshot into an Aurora cluster. Aurora to RDS has no snapshot path back; use `pg_dump` or logical replication. Before cutover, test autovacuum behavior, logical replication slots, and extension versions on Aurora. See [[backend/postgres-replication]] and [[comparisons/dynamodb-vs-postgres]] for the alternatives.

## Related

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