Aurora PostgreSQL: Features, Pricing, and When to Use It

Amazon Aurora PostgreSQL is AWS's managed PostgreSQL-compatible database. It promises up to 3x the throughput of standard PostgreSQL, automatic storage scaling up to 128 TB, and high availability across multiple availability zones. Those are the marketing claims. Here's what it looks like in practice.

What Aurora PostgreSQL actually is

Aurora isn't a fork of PostgreSQL. It's PostgreSQL's compute layer running on top of a custom distributed storage engine built by AWS. Your SQL, extensions, and client libraries stay the same. The difference is how data gets stored, replicated, and recovered.

The storage layer automatically replicates your data 6 ways across 3 availability zones. You can lose an entire AZ without downtime. Write availability survives losing 2 copies, and read availability survives losing 3.

For most applications, this means you get a PostgreSQL database that handles failover, replication, and storage growth without manual intervention.

Key features

Performance

Aurora's storage engine is designed for high-throughput OLTP workloads. Writes go to a log-structured storage system that avoids the traditional PostgreSQL WAL bottleneck. Reads benefit from a large buffer cache and SSD-backed storage.

In practice, you'll see the biggest gains on write-heavy workloads. Read-heavy workloads can benefit from Aurora Optimized Reads, which delivers up to 8x improved query latency for datasets that exceed instance memory. This is useful when you have large tables that don't fit in the buffer cache.

Auto-scaling storage

Aurora storage starts small and grows automatically up to 128 TB. You don't provision disk space, choose IOPS, or worry about running out of room at 3 AM. Storage is billed per GB-month, so you pay for what you use.

This is one of Aurora's best features for growing applications. With standard RDS, you need to predict storage needs or deal with resizing. Aurora removes that decision entirely.

Read replicas

You can create up to 15 read replicas within an Aurora cluster. They share the same storage layer, so replica lag is typically under 20 milliseconds. Adding a read replica takes minutes, not hours.

This is faster and cheaper than PostgreSQL logical replication, where each replica maintains its own copy of the data.

Global databases

Aurora Global Database lets you replicate across AWS regions with under 1 second of lag. The primary region handles writes, and secondary regions serve reads. If the primary region goes down, you can promote a secondary region in under a minute.

This is the feature that separates Aurora from standard RDS for global applications.

Serverless v2

Aurora Serverless v2 scales compute capacity up and down based on demand. It measures capacity in Aurora Capacity Units (ACUs), where 1 ACU equals roughly 2 GB of RAM. You set a minimum and maximum, and Aurora handles the rest.

Scaling happens in increments of 0.5 ACU and takes effect within seconds. For workloads that spike during business hours and go quiet at night, this can cut costs compared to running a provisioned instance 24/7.

Pricing breakdown

Aurora pricing has multiple components, which makes it harder to estimate than a fixed-price managed database.

Compute

Provisioned instances are priced per hour. Common options:

Instance	vCPUs	RAM	On-demand price (us-east-1)
db.t4g.medium	2	4 GB	~$0.073/hr ($53/mo)
db.r6g.large	2	16 GB	~$0.26/hr ($190/mo)
db.r6g.xlarge	4	32 GB	~$0.52/hr ($380/mo)
db.r6g.2xlarge	8	64 GB	~$1.04/hr ($760/mo)

Serverless v2 charges per ACU-hour. At ~$0.12/ACU-hour in us-east-1, a database that averages 4 ACUs costs roughly $350/month. But it can scale to zero-ish (minimum 0.5 ACU), bringing idle costs to around $44/month.

Reserved instances (1-year or 3-year commitment) reduce provisioned costs by 30-60%.

Storage

Aurora offers two storage configurations:

Standard: $0.10/GB-month for storage, plus $0.20 per million I/O requests. Good for workloads with moderate I/O.

I/O-Optimized: $0.225/GB-month for storage, no I/O charges. Better when I/O costs exceed roughly 25% of your total Aurora bill.

For a 100 GB database:

• Standard: $10/month storage + I/O charges
• I/O-Optimized: $22.50/month storage, no I/O charges

Other costs

• Backup storage: Free up to your total database size. Beyond that, $0.021/GB-month.
• Data transfer: Standard AWS data transfer rates. Cross-AZ replication traffic is included.
• Snapshots: Stored in S3, charged at standard S3 rates.

Realistic monthly costs

Workload	Configuration	Estimated cost
Dev/test	Serverless v2, min 0.5 ACU, 20 GB	$50-80/mo
Small production	db.r6g.large, 100 GB, Standard I/O	$250-400/mo
Medium production	db.r6g.xlarge, 500 GB, I/O-Optimized	$500-800/mo
Large production	db.r6g.2xlarge + 2 read replicas, 1 TB	$2,500-4,000/mo

Aurora vs standard RDS PostgreSQL

Standard RDS PostgreSQL runs stock PostgreSQL on EC2 instances with EBS storage. Here's how it compares:

Feature	Aurora PostgreSQL	RDS PostgreSQL
Storage scaling	Automatic to 128 TB	Manual, up to 64 TB
Replication	Shared storage, under 20ms lag	Streaming replication, higher lag
Read replicas	Up to 15	Up to 15 (but each has its own storage)
Failover time	~30 seconds	~60-120 seconds
Global replication	Built-in, under 1s lag	Manual setup required
Pricing	Higher base cost	Lower base cost
Serverless option	v2 (scales in seconds)	Not available

Choose Aurora when:

• You need fast, automatic failover
• Your application is read-heavy and benefits from low-lag replicas
• Storage management is a pain point
• You need global distribution
• Your workload is variable and Serverless v2 makes sense

Stick with RDS when:

• Cost is the primary concern
• Your workload is predictable and steady
• You don't need more than 1-2 read replicas
• Your database is under 100 GB and unlikely to grow fast

Aurora vs self-managed PostgreSQL

Running PostgreSQL on EC2 (or on-premises) gives you full control. You choose the PostgreSQL version, configure every parameter, and install any extension.

Aurora limits this somewhat. You can't access the underlying OS, you're restricted to AWS-supported PostgreSQL versions (currently up to PostgreSQL 16), and some extensions aren't available.

But self-managed PostgreSQL means you handle backups, failover, monitoring, patching, and storage management. For a small team, that's a significant operational burden.

The break-even point depends on your team. If you have a dedicated DBA, self-managed can be cheaper and more flexible. If your developers are managing the database alongside everything else, Aurora's automation pays for itself.

Aurora vs Neon

Neon is a newer serverless PostgreSQL option that's gained traction. Key differences:

• Scale to zero: Neon can scale to zero compute (truly $0 when idle). Aurora Serverless v2 has a minimum of 0.5 ACU.
• Branching: Neon offers database branching (like git branches). Aurora doesn't.
• Pricing model: Neon's free tier includes 0.5 GB storage and 191 compute hours. Aurora has no free tier.
• Ecosystem: Aurora has years of production use at scale. Neon is newer but growing fast.

For side projects and development, Neon's free tier and branching are compelling. For production workloads that need enterprise-grade availability, Aurora is the more proven choice.

When Aurora PostgreSQL is the right choice

Aurora makes the most sense when:

1. You're already on AWS. Aurora integrates tightly with IAM, CloudWatch, Secrets Manager, and other AWS services. If you're running on GCP or Azure, look at their managed PostgreSQL options instead.

2. You need high availability without complexity. Multi-AZ replication, automatic failover, and self-healing storage are built in. Getting the same setup with self-managed PostgreSQL requires significant effort.

3. Your database needs to scale. Auto-scaling storage, easy read replicas, and Serverless v2 make Aurora flexible as your application grows.

4. You can afford it. Aurora costs more than standard RDS for equivalent workloads. The premium pays for operational simplicity and better availability.

When to skip Aurora

• Budget-constrained startups: Neon or Supabase offer free tiers. Aurora doesn't.
• Simple applications: If your database is 5 GB and serves 100 requests per day, Aurora is overkill. A $15/month DigitalOcean managed database works fine.
• Multi-cloud strategies: Aurora is AWS-only. If vendor lock-in concerns you, stick with standard PostgreSQL.
• Heavy extension use: Some PostgreSQL extensions aren't supported on Aurora. Check the compatibility list before committing.

Getting started

If you decide Aurora PostgreSQL fits your needs:

1. Create an Aurora cluster in the AWS console or via Terraform/CloudFormation
2. Choose between provisioned instances and Serverless v2
3. Pick between Standard and I/O-Optimized storage
4. Connect using any PostgreSQL client or database tool like DB Pro
5. Enable Performance Insights for query monitoring

The connection process is identical to any PostgreSQL database. Your existing tools, ORMs, and client libraries will work without changes.