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 256 TiB on current versions, and high availability across multiple availability zones. Those are the marketing claims. Here's what it looks like in practice.

What Aurora PostgreSQL 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. The maximum is 256 TiB on Aurora PostgreSQL 17.5 and higher (and 16.9 and 15.13 onward), and 128 TiB on earlier versions. On current versions the volume also shrinks when you drop or truncate tables. You don't provision disk space, choose IOPS, or worry about running out of room at 3 AM. Storage is billed per GB-month for the space 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 AWS says replica lag "is usually much less than 100 milliseconds," rising during heavy write periods. 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 replicates from a primary region to up to 10 secondary regions, with lag typically under a second. The primary region handles writes, and secondary regions serve reads. If the primary region goes down, you can fail over to a secondary region, and planned switchovers run without data loss.

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.

Serverless v2 can also scale to zero. Set the minimum capacity to 0 ACUs and an instance pauses after a period with no connections (5 minutes by default), with no instance charge while paused. Storage is still billed. This needs Aurora PostgreSQL 16.3, 15.7, 14.12, 13.15, or higher. Resuming takes about 15 seconds, or 30 seconds or more after a pause longer than 24 hours, and features such as RDS Proxy, logical replication, and Global Database keep the instance awake.

How Aurora pricing works

Aurora pricing has several components, which makes it harder to estimate than a fixed-price managed database. AWS changes rates by region and over time, so check the Aurora pricing page or the AWS Pricing Calculator for current numbers.

Compute

Provisioned instances are billed per hour for each instance in the cluster, writer and readers alike. Memory-optimized classes such as db.r6g and db.r7g are the usual choice for production, and burstable db.t4g classes suit development. Reserved instances lower the hourly rate in exchange for a one- or three-year commitment.

Serverless v2 bills per ACU-hour for the capacity each instance uses. A cluster that averages a few ACUs through the day and pauses overnight can cost far less than a provisioned instance sized for peak load. A cluster that runs hot around the clock is usually cheaper on provisioned instances.

Storage and I/O

Aurora offers two storage configurations:

Aurora Standard has lower storage and instance rates, plus a charge per million I/O requests. It suits workloads with moderate I/O.

Aurora I/O-Optimized removes I/O charges in exchange for higher storage and instance rates. AWS recommends it when I/O is 25% or more of your Aurora spend. You can switch from Standard to I/O-Optimized once every 30 days, and back at any time.

Other costs

• Backup storage: free up to the size of your cluster's data, billed per GB-month beyond that.
• Data transfer: standard AWS data transfer rates apply. Replication between the six storage copies is not billed separately.
• Extras: Global Database replication, snapshot exports, and CloudWatch Database Insights beyond its free Standard mode each add their own charges.

The biggest cost driver for most teams is the number of instances. A highly available cluster needs at least one reader in another availability zone, and that reader bills as a full instance.

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, up to 256 TiB	Allocated up front, up to 64 TiB
Replication	Shared storage, lag usually under 100 ms	Streaming replication, lag depends on write load
Read replicas	Up to 15	Up to 15 (but each has its own storage)
Failover time	Under 60 seconds, often under 30	60-120 seconds (Multi-AZ instance), under 35 (Multi-AZ DB cluster)
Global replication	Global Database, lag typically under 1s	Cross-region read replicas
Pricing	Higher base cost	Lower base cost
Serverless option	v2, including scale to zero	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:

• You want new PostgreSQL major versions soon after release (RDS supported PostgreSQL 18 in November 2025, Aurora in June 2026)
• 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 (Aurora added PostgreSQL 18 in June 2026, months after the community release), 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: both can now pause idle compute. Aurora Serverless v2 takes about 15 seconds to resume and only pauses when features such as RDS Proxy or Global Database are off.
• Branching: Neon offers database branching (like git branches). Aurora offers fast clones, which are copy-on-write copies of a cluster rather than a branching workflow.
• Pricing model: Neon has a permanent free plan. Aurora has no always-free tier, and even a paused cluster pays for storage.
• Ecosystem: Aurora has years of production use at scale. Neon is newer but growing fast.

For side projects and development, Neon's free plan and branching are compelling. Our Neon vs Aurora Serverless comparison goes deeper. 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 plans. Aurora doesn't.
• Simple applications: If your database is 5 GB and serves 100 requests per day, Aurora is overkill. A small managed PostgreSQL instance on RDS or another provider 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're still weighing Aurora against RDS, our Aurora vs RDS comparison covers both PostgreSQL and MySQL. 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. Turn on CloudWatch Database Insights for query monitoring (it replaced the Performance Insights console on July 31, 2026)

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