Aurora PostgreSQL vs RDS PostgreSQL

Quick verdict

Amazon Aurora PostgreSQL-Compatible Edition is AWS's PostgreSQL-compatible engine on Aurora's shared cluster storage. Its version numbers follow the community release they are based on (Aurora PostgreSQL 18.6 is based on PostgreSQL 18.6), and AWS adds Aurora-specific functions, extensions and features on top.

Amazon RDS for PostgreSQL runs the community PostgreSQL engine on DB instances with EBS storage, managed by AWS. It is the closer of the two to upstream PostgreSQL, with RDS restrictions such as no host access and an rds_superuser role instead of a true superuser.

This page looks only at what differs for PostgreSQL users: versions, extensions, PostgreSQL features each one adds or omits, and replication. Storage, Serverless v2, cloning and the general cost model are covered in Amazon RDS vs Amazon Aurora, and the engine choice itself in MySQL vs PostgreSQL.

Side by side

Key differences

Versions: how far behind Aurora runs, and LTS minors

Both services currently support PostgreSQL 14 to 18 in standard support, and both list the same end-of-standard-support dates (PostgreSQL 14 on 28 February 2027, PostgreSQL 18 on 28 February 2031). The gap is in when releases arrive. RDS for PostgreSQL commits to new majors within 30 days of the community's first minor and to minors within 7 days. Aurora PostgreSQL commits to majors within 8 months and minors within 3 months.

The release calendars show the effect on minors in 2026: PostgreSQL 18.4 reached RDS on 14 May 2026 and Aurora on 21 August 2026; 18.6 reached RDS on 25 August 2026 and Aurora on 29 September 2026. Aurora's first PostgreSQL 18 release was 18.3, so Aurora never shipped 18.1 or 18.2.

In return, Aurora PostgreSQL offers long-term support (LTS) minor versions for teams that want to stay on one minor across several release cycles. The current LTS minors are 14.6, 15.10, 16.8 and 17.7, each supported until its major's end of standard support; AWS targets an LTS within 12 months of each Aurora major release, so PostgreSQL 18 has none yet. RDS for PostgreSQL has no LTS minors, and its older minors leave standard support on their own dates (for example 17.5 and 17.6 on 31 October 2026).

Extensions: mostly the same, with a few one-sided ones

For PostgreSQL 18 the two extension tables are very close. Both list vector (pgvector 0.8.2), PostGIS 3.6.3, pg_cron 1.6.7, pg_partman 5.4.3, pglogical 2.4.8, pg_tle 1.5.2 (Trusted Language Extensions), orafce, pg_hint_plan, pg_repack, h3-pg, pgAudit and the aws_s3 and aws_lambda integrations. If your application relies on common community extensions, either service is likely to have them; check the exact version for your minor in the table before migrating, because extensions are not upgraded automatically with the engine.

The differences in the PostgreSQL 18 tables: Aurora lists apg_plan_mgmt (query plan management, which can capture and enforce approved plans), aws_ml (calls to Amazon SageMaker and Amazon Comprehend) and pg_columnmask (dynamic data masking), none of which appear in the RDS table. RDS lists pgactive (active-active replication between instances) and Percona's pg_stat_monitor, which do not appear in the Aurora PostgreSQL 18 table. Neither table lists plrust for PostgreSQL 18.

Babelfish: SQL Server clients on Aurora PostgreSQL

Babelfish for Aurora PostgreSQL adds a second endpoint that speaks Microsoft's Tabular Data Stream (TDS) protocol, versions 7.1 to 7.4. SQL Server clients connect on port 1433 and send T-SQL, while PostgreSQL clients keep using port 5432 against the same data. AWS documents it on all supported Aurora PostgreSQL versions from 13, describes it as a built-in capability with no additional cost, and publishes the code under the Apache 2.0 and PostgreSQL licences (babelfishpg.org). You turn it on when you create the cluster (the rds.babelfish_status cluster parameter) and choose a single-database or multiple-database migration mode; multiple databases is the default from Aurora PostgreSQL 16.

It is not a full SQL Server: AWS maintains a list of T-SQL differences and unsupported features, and a snapshot restored from a Babelfish cluster does not come back as a Babelfish cluster until you set the parameters again. Logical replication works with Babelfish from 15.7 and 16.3. There is no equivalent on RDS for PostgreSQL. If you are weighing a SQL Server move in general, see SQL Server vs PostgreSQL.

Limitless Database: sharding inside Aurora PostgreSQL

Aurora PostgreSQL Limitless Database, generally available since 31 October 2024, spreads tables across shards behind routers in a DB shard group, while applications connect to one endpoint. It runs on special engine versions (currently 16.x-limitless, the latest being 16.11-limitless from February 2026), uses only the Aurora I/O-Optimized storage configuration, and is available in all AWS Regions except Asia Pacific (Taipei). A shard group's maximum capacity can be set from 16 to 6,144 ACUs; you can have one shard group per cluster and up to five per Region.

You choose sharded or reference tables with session variables. This is the documented pattern for a sharded table:

-- Aurora PostgreSQL Limitless Database
BEGIN;
SET LOCAL rds_aurora.limitless_create_table_mode='sharded';
SET LOCAL rds_aurora.limitless_create_table_shard_key='{"id"}';
CREATE TABLE items(id int, val int, item text);
COMMIT;

The constraints are significant. Primary and unique keys must include the shard key, shard keys cannot be updated, SERIALIZABLE isolation is not available, shards cannot be merged, and not every extension or SQL command is supported. AWS lists features that do not work with Limitless Database, including Babelfish, Global Database, Blue/Green Deployments, RDS Proxy, cloning, read replicas, zero-ETL integrations, AWS Backup and Lambda integration. RDS for PostgreSQL has no built-in sharding; in our assessment, Limitless is worth evaluating only when a single writer genuinely cannot keep up.

Failover: cluster cache management and client settings

After a failover the new writer normally starts with a cold buffer cache. Aurora PostgreSQL's cluster cache management addresses that: you set the apg_ccm_enabled cluster parameter to 1, give the writer and one reader of the same instance class promotion tier 0, and Aurora keeps that reader's cache synchronised with the writer's so it starts warm if promoted. The aurora_ccm_status() function reports progress. AWS recommends running no workload on that designated reader, and the feature is not supported on Global Database secondary clusters.

AWS also publishes fast failover guidance for Aurora PostgreSQL clients: short TCP keepalives (an idle of 1 second, interval of 1 second and count of 5, which AWS says detects a dead server within about five seconds), a low DNS cache TTL, connection strings that list the cluster writer and reader endpoints with targetServerType=primary, and the AWS Advanced JDBC Wrapper. RDS for PostgreSQL handles failover through Multi-AZ: a single standby on a Multi-AZ DB instance, or, on a Multi-AZ DB cluster, promotion of whichever of the two readers has the lowest replica lag, with a flow-control extension that throttles writes if readers fall more than two minutes behind.

Logical replication and change data capture

Both services support native publications and subscriptions, the pglogical extension and the wal2json decoder, and both turn logical replication on with the static rds.logical_replication parameter and a reboot. On Aurora the WAL lives in Aurora storage, and since 14.5 Aurora adds a write-through cache to reduce storage reads during logical decoding.

The notable gap is replicas. PostgreSQL 16 added logical decoding on standbys, and RDS for PostgreSQL supports it from 16.1 on read replicas, with slots that survive promotion of that standby, and on the readers of a Multi-AZ DB cluster. The Aurora documentation states that this feature is not supported on Aurora PostgreSQL, so CDC tools must read from the writer. Remember that an unconsumed logical slot holds WAL: on RDS that fills the instance's allocated storage, and on Aurora it grows billed storage.

Pricing and licensing

Aurora PostgreSQL. Billed per instance-hour or per ACU-hour for Serverless v2, plus storage used, backups and data transfer. Listed on the Aurora pricing page in October 2026 for US East (N. Virginia), in USD: Aurora Standard storage 0.10 per GB-month plus 0.20 per million I/O requests; Aurora I/O-Optimized storage 0.225 per GB-month with no I/O charges; Serverless v2 0.12 per ACU-hour on Standard and 0.156 on I/O-Optimized. Limitless Database is billed in ACUs per second and requires I/O-Optimized, plus the monitoring and logging features it mandates. Babelfish has no extra charge, per AWS.

RDS for PostgreSQL. Billed per instance-hour (On-Demand or Reserved), per GB-month of allocated storage by volume type, plus provisioned IOPS and throughput above the gp3 baseline, backups and data transfer, with no per-request I/O charge. As one example, AWS's published On-Demand rate for a db.m7g.large in US East (N. Virginia) in October 2026 is 0.168 USD per hour for a Single-AZ instance. Both services charge RDS Extended Support fees for majors past end of standard support. Use the AWS Pricing Calculator for a real comparison, because the answer depends on replica count and I/O volume.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want serverless Postgres with database branching per pull request: see Neon vs AWS RDS.
• You want PostgreSQL plus auth, storage and APIs as one platform: see Supabase vs AWS RDS.
• You are comparing clouds rather than AWS options: see AWS RDS vs Google Cloud SQL.
• You have not settled on PostgreSQL yet: see AWS RDS MySQL vs RDS PostgreSQL and MySQL vs PostgreSQL.

Final recommendation

Frequently asked questions

Sources

• Aurora PostgreSQL release calendars
• RDS for PostgreSQL release calendars
• Aurora PostgreSQL extension versions
• RDS for PostgreSQL extension versions
• Aurora User Guide: Using Babelfish for Aurora PostgreSQL
• Babelfish for Aurora PostgreSQL product page
• Aurora User Guide: Limitless Database requirements and considerations
• AWS: Aurora PostgreSQL Limitless Database is generally available (October 2024)
• Aurora User Guide: Cluster cache management
• Aurora User Guide: Fast failover with Aurora PostgreSQL
• Aurora User Guide: Logical replication with Aurora PostgreSQL
• RDS User Guide: Logical decoding on a read replica
• Amazon Aurora pricing
• Amazon RDS for PostgreSQL pricing

Checked October 2026.

How we research comparisons: our editorial method.