What Is Amazon Aurora PostgreSQL
Amazon Aurora PostgreSQL is an AWS-managed relational database that is fully compatible with standard PostgreSQL. The fundamental difference from conventional RDS PostgreSQL lies in its architecture: Aurora was designed as a cloud-native service, with distributed storage and built-in replication from the ground up.
In practice, this means it is not simply a PostgreSQL instance running on a managed EC2 machine. AWS redesigned the storage layer to leverage distributed infrastructure, resulting in up to 3x more throughput than a standard PostgreSQL installation on equivalent hardware.
Aurora accepts the same driver, the same extensions, and the same SQL commands you already use with PostgreSQL. Code migration is, in most cases, transparent. The difference is in how data is stored, replicated, and recovered.
Aurora’s Internal Architecture
Separation of compute and storage
In traditional RDS PostgreSQL, compute and storage are coupled within the same instance. Aurora separates these two layers: database instances process queries, while storage lives in an independent distributed cluster.
This separation has important consequences:
- Scaling reads does not require duplicating storage. Read replicas share the same data volume.
- Storage grows automatically from 10 GiB to 128 TiB, with no need to manually provision disk.
- Failover is faster because the new instance does not need to rebuild local data.
Distributed storage and fault tolerance
Aurora maintains 6 copies of your data distributed across 3 Availability Zones. This model tolerates:
- Loss of up to 2 copies without impact on write capability
- Loss of up to 3 copies without impact on read capability
Each write operation is acknowledged when 4 of the 6 copies respond (write quorum). For reads, 3 copies suffice. This eliminates the need for complex synchronous replication setups that would be required to achieve a similar level of durability on RDS.
Log-Based Storage
A significant architectural difference: Aurora sends only WAL (Write-Ahead Log) records to the storage layer. Data pages are materialized directly in the distributed storage, eliminating traditional checkpoints.
In standard PostgreSQL, checkpoints are heavy operations that pause writes to sync dirty pages from the buffer pool to disk. Without this requirement, Aurora maintains more stable throughput, especially under intense write loads.
The direct result: crash recovery is nearly instantaneous, and the replication lag between the primary instance and read replicas stays typically below 100ms, since replicas consume directly from the same storage volume. All transactions maintain full ACID properties.
Comparison: Aurora PostgreSQL vs RDS PostgreSQL
| Aspect | Aurora PostgreSQL | RDS PostgreSQL |
|---|---|---|
| Storage | Distributed, 6 copies across 3 AZs, up to 128 TiB | EBS per instance, up to 64 TiB |
| Replication | Shared volume, lag < 100ms | WAL-based, lag from seconds to minutes |
| Failover | Native Multi-AZ, ~30 seconds | Optional Multi-AZ, 1-2 minutes |
| Read replicas | Up to 15 replicas | Up to 5 replicas |
| Performance | No local checkpoints, up to 3x more throughput | Standard PostgreSQL, depends on tuning |
| Global Database | Native support, cross-region replication | Not available |
| Backups | Continuous and incremental to S3 | Daily snapshots |
| Base cost | ~20% more expensive (instance + I/O) | More economical for predictable workloads |
The central point of this comparison is not that Aurora is universally superior. It solves specific problems — high availability, massive read replication, fast failover — that on RDS would require significant manual configuration and still would not reach the same level of reliability.
Aurora Serverless v2
Aurora Serverless v2 eliminates the need to choose and manage instance classes. The database automatically scales compute capacity based on actual demand.
How it works
The unit of measure is the ACU (Aurora Capacity Unit). Each ACU is approximately 2 GiB of RAM with proportional CPU. The cluster scales continuously between configured limits:
- Minimum: 0.5 ACU
- Maximum: 128 ACUs
Scaling happens granularly, in 0.5 ACU increments, with sub-second adjustments and no interruption to connections or in-flight queries.
Pricing
You are billed per ACU-hour consumed. In the Sao Paulo region (sa-east-1), the cost is approximately $0.16 to $0.18 per ACU-hour.
For reference:
| Scenario | Estimated ACUs | Approximate monthly cost |
|---|---|---|
| Light application, business hours | 2-4 ACUs (8h/day) | ~$80-150 |
| API with evening spikes | 4-16 ACUs (variable) | ~$300-700 |
| Constant heavy workload | 16-32 ACUs (24/7) | ~$1,900-4,200 |
Serverless v2 is particularly advantageous for unpredictable workloads. If the database sits idle at night, it scales down to the configured minimum. If a traffic spike hits at 3 AM, it scales up in seconds without manual intervention.
Serverless v2 vs provisioned instances
For workloads with constant and predictable load, provisioned instances are still more cost-effective. Serverless v2 pays off when workload variability is high enough to justify paying a premium per ACU in exchange for not maintaining idle capacity.
Scalability
Vertical scaling
As with RDS, you can change the instance class (db.r6g.large, db.r6g.xlarge, etc.) to increase CPU and memory. This operation causes brief downtime, typically a few minutes.
Horizontal scaling
Aurora supports up to 15 read replicas in the same cluster. All share the same storage volume, so adding a replica does not duplicate data.
Aurora Auto Scaling automatically adjusts the number of read replicas based on metrics such as CPU usage or connection count. You define the minimum and maximum capacity, and Aurora creates or removes replicas as demand changes.
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:my-aurora-cluster \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8Aurora Global Database
For applications with users in multiple regions, Aurora Global Database replicates data across AWS regions with less than 1 second of latency. The primary region handles writes, while secondary regions serve local reads with low latency.
In the event of a regional disaster, promoting a secondary region to primary takes less than 1 minute — no backup restoration required.
When to Migrate to Aurora
Choose Aurora when
- High availability is critical: failover in ~30 seconds and replication with minimal lag are business requirements, not just nice-to-haves.
- Read-heavy workloads: the application has far more reads than writes and needs more than 5 read replicas.
- Variable workloads: traffic fluctuates significantly (Serverless v2) or the database grows rapidly (auto-expanding storage).
- Multi-region: users in different regions need low-latency reads (Global Database).
RDS PostgreSQL is sufficient when
- Small, predictable workload: an application with few users and constant load does not benefit from Aurora’s distributed architecture.
- Tight budget: RDS is 10-20% cheaper for the same instance class. If monthly cost matters, RDS may be sufficient.
- Failover is not critical: if the application tolerates 1-2 minutes of downtime during failover, RDS Multi-AZ is adequate.
- Strict compatibility: in rare cases, specific PostgreSQL extensions or versions may be available on RDS before Aurora.
Migration path
AWS offers native migration with minimal downtime:
- Create a snapshot of the RDS PostgreSQL instance
- Restore the snapshot as an Aurora PostgreSQL cluster
- Use AWS DMS (Database Migration Service) for continuous replication during the transition
- Redirect the application to the Aurora endpoint
- Validate and decommission the original RDS instance
For smaller databases, the entire process can take less than 1 hour. For databases of hundreds of GiB, plan an appropriate maintenance window.
Conclusion
Aurora PostgreSQL is not an automatic replacement for RDS. It is an architectural option that makes sense when availability, replication, and scalability requirements justify the additional cost. For most early-stage applications or those with moderate load, RDS PostgreSQL remains the more pragmatic and cost-effective choice.
The practical recommendation: start with RDS PostgreSQL. Monitor replication, failover, and throughput metrics. When those indicators show that RDS is reaching its limits — or when business criticality demands stronger guarantees — migrate to Aurora with concrete data justifying the decision.