PostgreSQL at Scale on AWS: RDS, Aurora, Global Aurora, and RDS Proxy Explained

• 1. RDS PostgreSQL + Read Replicas
• 2. RDS Multi-AZ (High Availability)
• 3. Aurora PostgreSQL (Single Region)
• 4. Aurora Global Database (Multi-Region)
• 5. RDS Proxy
• Feature Comparison Summary

Running PostgreSQL on AWS seems simple at first — choose an RDS instance and go. But as soon as you need high availability, read scaling, global access, or automatic failover, you quickly discover that AWS actually offers five different architectural patterns:

• RDS PostgreSQL with Read Replicas

• RDS Multi-AZ

• Aurora PostgreSQL

• Aurora Global Database

• RDS Proxy

They all solve different problems, and they all have limitations. This article explains each option clearly — what it offers, what it lacks, and when it makes sense — especially in terms of autoscaling, failover behavior, global distribution, backups, and traffic routing.

By the end, you'll know exactly which architecture fits your production workloads.

1. RDS PostgreSQL + Read Replicas

RDS PostgreSQL is the classic managed PostgreSQL on AWS. Add read replicas and you get basic horizontal read scaling.

What it offers

• Primary + Read Replicas (asynchronous)

• Read scaling (multiple replicas)

• Can auto-scale replica count with CloudWatch + Application Auto Scaling

• Can create replicas cross-AZ or cross-region

• Managed automated backups and PITR (point-in-time restore)

What it lacks

• No automatic failover to replicas If the primary dies, you must manually promote a replica.

• No single read/write endpoint Each replica has its own connection string — your app must split reads and writes.

• Writes don’t scale Only the primary handles writes; scaling means a manual instance resize with downtime.

• Replication lag Because replication is async, replicas can lag seconds or minutes under load.

Best for

• Simple architectures

• Mostly read-heavy traffic

• Teams comfortable with handling failover and routing logic manually

2. RDS Multi-AZ (High Availability)

Multi-AZ is an HA feature, not a scaling solution.

What it offers

• Primary + Standby in a different AZ

• Automatic failover within the same region

• Same connection string — AWS updates it to point to the new primary

• Synchronous replication to ensure data durability

• Automated backups still work normally

What it lacks

• No read scaling The standby replica is not queryable.

• No autoscaling of compute or storage except manual instance resizing.

• No global read replicas or multi-region access.

Best for

OLTP applications that want reliable high availability

Teams that don’t need read scaling

Multi-AZ = uptime + durability. Not throughput.

3. Aurora PostgreSQL (Single Region)

Aurora is a cloud-native engine re-designed for resilience and scale.

Instead of tying compute to storage, Aurora stores your data in a distributed storage volume replicated 6 times across 3 AZs.

What it offers

• A writer + up to 15 reader instances

• Automatic failover to a reader instance

• Reader endpoint for automatic load balancing across replicas

• Writer endpoint, stable even after failover

• Storage autoscaling (up to dozens of TB)

• Reader autoscaling (add/remove replicas dynamically)

• Aurora Serverless v2 — true automated compute scaling

• Faster failover than RDS (seconds vs tens of seconds)

What it lacks

• Only one writer per cluster

• Cross-region replication is not built-in (that’s Aurora Global)

• Serverless v2 still has some feature limitations compared to provisioned Aurora

• Higher cost than RDS

Best for

• High throughput OLTP workloads

• Applications needing read scaling and automatic failover

• Teams wanting simpler connection management: one writer endpoint + one reader endpoint

If you want serious scale in a single region, this is usually the right choice.

4. Aurora Global Database (Multi-Region)

Aurora Global Database extends Aurora across multiple AWS regions.

What it offers

• One primary region (read/write)

• Up to 5 secondary regions, each with:

• Local reader instances

• Local reader endpoints for low-latency reads

• Global replication at storage layer, usually <1 second lag

• Cross-region disaster recovery — promote a secondary region to become the new writer

• Per-region autoscaling of readers and storage

What it lacks

• Still single-writer — writes from other regions incur cross-region ping

• Failover across regions is not automatic You must promote manually or automate with Lambda.

• More complex and expensive

Best for

• Global applications (e.g., SaaS with customers in EU, US, APAC)

• Low-latency reads needed everywhere

• Disaster recovery across continents

Aurora Global = Aurora but worldwide.

5. RDS Proxy

RDS Proxy is not a database — it’s a connection pooling and failover smoothing layer.

What it offers

• Connection pooling for RDS and Aurora

• Protects database from connection storms (Lambda, Fargate, serverless apps)

• Automatically follows failover events

• Improves app resiliency (fewer dropped connections)

• Can point to writer or reader endpoints

What it lacks

• Doesn’t scale storage or compute

• Doesn't add replication or multi-region capabilities

• Doesn’t split reads/writes automatically

Best for

• Apps with thousands of short-lived connections

• Reducing failover impact

• Enhancing Aurora/RDS reliability without changing application code

Think of Proxy as "shock absorbers" for your database layer.

Feature Comparison Summary