Aurora PostgreSQL: Setup, Pricing & Performance Tips (2026)

Short answer

AWS Aurora PostgreSQL supports PostgreSQL majors up to 18 (released on Aurora on 11 June 2026); 13 and older now run only under paid RDS Extended Support.
In the console a cluster and its writer are created together; with the CLI you run create-db-cluster and then create-db-instance for the writer.
Connect writes to the cluster endpoint and reads to the reader endpoint on port 5432; Babelfish adds a T-SQL endpoint on port 1433 for SQL Server clients.
Aurora Postgres Serverless (Serverless v2) is billed per ACU-hour and can pause at 0 ACUs; provisioned clusters are billed per instance-hour.
AWS's performance guidance centres on fast failover settings, cluster cache management, connection pooling, query plan management and Optimized Reads.

How we know: Research-based: versions, setup steps, CLI options, endpoints, Babelfish, best practices and prices were checked against the Amazon Aurora User Guide, the Aurora PostgreSQL release notes, the AWS CLI reference and the Amazon Aurora pricing page on 8 October 2026. The performance tips are AWS's documented recommendations; we have not run Aurora clusters or measured performance for this guide.

What AWS Aurora PostgreSQL is

Amazon Aurora PostgreSQL (Aurora for PostgreSQL, often just Aurora Postgres) is a fully managed, PostgreSQL-compatible engine that runs on Aurora's shared cluster storage. AWS describes it as a drop-in replacement for PostgreSQL with push-button migration from RDS for PostgreSQL. Your SQL, drivers and most extensions carry over; what changes is the storage layer, replication, failover and the extra Aurora features.

For the architecture behind it (cluster volume across three Availability Zones, up to 15 replicas, I/O-Optimized, Global Database) see the related Amazon Aurora guide. For the choice between this and plain RDS see Aurora PostgreSQL vs RDS PostgreSQL.

Aurora PostgreSQL versions

AWS says new Aurora PostgreSQL major versions arrive within 8 months of the community's first minor release, and that majors stay in standard support at least until community end of life. Past that, clusters move to RDS Extended Support, which is charged per vCPU-hour (or per ACU-hour for serverless).

Aurora PostgreSQL major versions (AWS release calendar, checked 8 October 2026)
PostgreSQL major	Aurora release date	Aurora end of standard support	Status
18	11 June 2026	28 February 2031	Standard support
17	1 May 2025	28 February 2030	Standard support
16	31 January 2024	28 February 2029	Standard support
15	8 February 2023	29 February 2028	Standard support
14	24 February 2022	28 February 2027	Standard support, ending soon
13	26 August 2021	28 February 2026	Extended Support only

Creating an Aurora PostgreSQL cluster

Console. AWS's documented flow is: choose Create database, select Aurora (PostgreSQL Compatible) and a version; pick provisioned instances or Aurora Serverless; set the cluster identifier and master username (with the password managed in Secrets Manager if you like); choose the cluster storage configuration, Aurora I/O-Optimized or Aurora Standard; then set the VPC, subnet group and security group. AWS notes that if you choose to create a new security group in the console, it gets an inbound rule for your local computer's IP address. The console creates the writer instance for you.

CLI. With the CLI you create the cluster and then, separately, the writer, because until a writer exists the cluster endpoints stay in Creating status. Using options from AWS's CLI reference (names and IDs are placeholders):

aws rds create-db-cluster --db-cluster-identifier app-apg --engine aurora-postgresql --engine-version 17 --storage-type aurora-iopt1 --master-username postgres --manage-master-user-password --db-subnet-group-name app-subnets --vpc-security-group-ids sg-0123example --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=8

aws rds create-db-instance --db-instance-identifier app-apg-writer --db-cluster-identifier app-apg --engine aurora-postgresql --db-instance-class db.serverless

Use --storage-type aurora for Aurora Standard, and a provisioned class such as db.r6i.large instead of db.serverless for a provisioned writer. Add readers with further create-db-instance calls against the same cluster.

Parameter groups: cluster and instance

Aurora PostgreSQL has two levels of parameter groups. The DB cluster parameter group holds settings that apply across the cluster (for example apg_ccm_enabled for cluster cache management) and defaults for the instances; the DB parameter group holds per-instance settings. Create custom groups before launch if you know you will change settings.

Connecting: endpoints, psql and Babelfish

An Aurora PostgreSQL cluster exposes a cluster endpoint (name.cluster-xxxx.region.rds.amazonaws.com) that always points at the writer and accepts reads and writes, and a reader endpoint (name.cluster-ro-xxxx...) that balances read-only connections across the replicas. Connect with psql exactly as for any PostgreSQL server, on port 5432 unless you changed it:

psql --host=<cluster endpoint> --port=5432 --username=postgres --dbname=postgres

pgAdmin, DBeaver and DataGrip use the same host, port and credentials; see the best PostgreSQL GUI tools.

Babelfish. Babelfish for Aurora PostgreSQL lets a cluster accept connections from SQL Server clients over the TDS protocol. AWS says applications built for SQL Server can work with few code changes and without changing drivers. T-SQL clients connect on port 1433 and PostgreSQL clients on 5432, to the same data. Babelfish runs T-SQL with documented differences from SQL Server, so check AWS's compatibility notes before you plan a migration; see also SQL Server vs PostgreSQL.

Aurora PostgreSQL performance tips (AWS best practices)

These are AWS's documented recommendations, not results we have measured:

Monitor before you scale. AWS warns that a workload that exhausts CPU, memory or connections can slow the instance, restart it or trigger a failover; watch CloudWatch and Database Insights and scale up before you reach the limits.
Configure clients for fast failover. Set TCP keepalives aggressively (tcp_keepalives_idle and related settings), keep DNS caching short so the reader endpoint can rotate, and consider the AWS JDBC Driver, which AWS documents for faster failover handling.
Keep a warm failover target. Cluster cache management keeps a designated reader's buffer cache in sync with the writer so it starts warm after failover. It requires the reader to have the same instance class and size as the writer.
Pool connections. AWS's best-practice list includes managing connection churn with pooling. In our view this matters most for serverless functions and other clients that open many short-lived connections; RDS Proxy is the managed option (see the related guide).
Stabilise plans. Query plan management (the apg_plan_mgmt extension) lets you capture and approve execution plans so that optimizer changes do not suddenly alter critical queries.
Use Optimized Reads for large data sets. On NVMe-based instance classes (R6gd, R8gd, R6id), Optimized Reads adds a tiered cache of up to 5x the instance memory and local storage for temporary objects; AWS claims up to 8x better query latency. Tiered cache needs the I/O-Optimized configuration.
Get the indexes right. Most slow queries are index or query problems; see our SQL indexes lesson.

Pricing

Prices from the provider's official pricing pages, checked 8 October 2026, region US East (N. Virginia), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.

Aurora PostgreSQL is billed like the rest of Aurora: instance-hours for provisioned instances or ACU-hours for serverless, storage per GB-month, I/O per million requests on Aurora Standard (none on I/O-Optimized), backups beyond 100% of the cluster size, and data transfer. There is no PostgreSQL licence fee. The pricing page also lists a Free Tier plan for new customers covering Aurora PostgreSQL serverless instances with up to 4 ACUs and 1 GiB of storage per cluster.

Rates from AWS's Aurora pricing page examples, US East (N. Virginia)
Item	Aurora Standard (USD)	Aurora I/O-Optimized (USD)
Serverless capacity	0.12 per ACU-hour	0.156 per ACU-hour
db.r6i.large provisioned instance	0.29 per hour	0.377 per hour
Storage	0.10 per GB-month	0.225 per GB-month
Read and write I/O	0.20 per 1 million requests	No charge

Estimate: development cluster on Serverless with auto-pause

One serverless writer, minimum 0 ACUs, active 8 hours a day on 22 working days (176 hours) at an average of 1 ACU, paused otherwise.
Aurora Standard, 10 GB of data, 5 million I/O requests in the month, US East (N. Virginia).
Excludes backups beyond the free allowance, data transfer and tax.

Item	Basis	Estimated per month
Serverless capacity	176 hours x 1 ACU x 0.12 USD	21.12 USD
Storage	10 GB x 0.10 USD	1.00 USD
I/O requests	5 million x 0.20 USD per million	1.00 USD
Estimated total		23.12 USD per month

Estimate: production serverless writer on I/O-Optimized

One serverless writer averaging 4 ACUs around the clock (730 hours), Aurora I/O-Optimized, 200 GB of data.
No reader; add the same capacity again for each reader. Excludes backups, data transfer and tax.

Item	Basis	Estimated per month
Serverless capacity	4 ACUs x 730 hours x 0.156 USD	455.52 USD
Storage	200 GB x 0.225 USD	45.00 USD
I/O requests	Included	0.00 USD
Estimated total		500.52 USD per month

Worked examples are estimates calculated from the list prices above; they are not quotes or measured bills.

Frequently asked questions

Is Aurora PostgreSQL the same as PostgreSQL?

It is PostgreSQL-compatible: the SQL, wire protocol, drivers and most extensions are the same, and AWS calls it a drop-in replacement. The storage, replication and failover layers are Aurora's own, and the supported extension list and versions are published separately for Aurora PostgreSQL, so check your extensions before migrating.

How does Aurora Postgres Serverless pricing work?

You pay per ACU-hour for the capacity each serverless instance uses, which AWS measures every second as the instance scales, plus storage and (on Aurora Standard) I/O. AWS's examples use 0.12 USD per ACU-hour on Standard and 0.156 USD on I/O-Optimized in US East (N. Virginia). At a minimum of 0 ACUs, paused instances have no capacity charge.

Why does my CLI-created Aurora cluster have no endpoint?

AWS documents that when you create a cluster with the CLI or API you must create the writer instance yourself with create-db-instance; until then the cluster endpoints remain in Creating status.

What port does Babelfish use?

By default SQL Server (T-SQL) clients connect to port 1433 and PostgreSQL clients to port 5432 on the same Babelfish-enabled cluster.

Should I use the cluster endpoint or the reader endpoint?

Send writes and read-your-own-write queries to the cluster endpoint, and read-only traffic that tolerates slight replica lag to the reader endpoint, which balances connections across replicas.

Sources

Checked 8 October 2026.

How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.