PostgreSQL vs Aurora PostgreSQL vs RDS: Architecture, Billing, Version Support and When to Self-Manage

The short answer

Choose Aurora PostgreSQL when you are committed to AWS and want fast failover, many read replicas on shared storage and capacity that can scale with load. Choose RDS for PostgreSQL when you want a managed service that stays close to community PostgreSQL with simpler storage. Choose self-managed PostgreSQL when you need superuser access, any extension, your own version calendar, or the freedom to run the same database in any cloud or data centre. All three speak the PostgreSQL protocol and SQL, so applications move between them more easily than between different databases. What changes is who runs the database, what you are allowed to change, and how the bill is built.

PostgreSQL vs Aurora vs RDS at a glance

What Aurora actually is

AWS describes Aurora as a fully managed relational engine compatible with MySQL and PostgreSQL, and as part of Amazon RDS. It uses the same console, CLI and API as RDS for provisioning, patching, backup and recovery. The difference is underneath. Aurora stores data in a cluster volume, a single virtual volume with copies of the data across three Availability Zones, six copies in all. Every instance in the cluster reads that same volume. Adding a reader does not copy table data, because the new instance attaches to the volume that already holds it.

That design is why Aurora replicas come quickly and stay close behind the writer: AWS says replica lag is usually well under 100 milliseconds. A cluster can have up to 15 Aurora Replicas, and if the writer fails, Aurora promotes one of them. An Aurora PostgreSQL global database can add up to 10 read-only secondary clusters in other Regions.

Aurora is compatible with PostgreSQL, not identical to it. Aurora versions have their own numbers alongside the community version, visible through the aurora_version() function, and AWS ships Aurora minor versions on its own schedule, usually quarterly. Your SQL, drivers and most extensions behave as they do on community PostgreSQL. The storage engine, replication and crash recovery are AWS's own.

RDS for PostgreSQL: community PostgreSQL, run for you

RDS for PostgreSQL runs the community engine on instances with provisioned storage. High availability comes from a Multi-AZ deployment. A Multi-AZ DB instance deployment keeps one standby in another Availability Zone that provides failover but does not serve reads. A Multi-AZ DB cluster deployment keeps two standbys that provide failover and can also serve read traffic.

RDS suits teams that want AWS to handle backups, minor upgrades and failover, but want the database to stay as close as possible to what runs on a laptop or in another cloud.

Self-managed PostgreSQL: full control, full responsibility

On your own servers, VMs or Kubernetes, you run community PostgreSQL exactly as the project ships it. You get the superuser account, any extension you can build, any configuration parameter, and the choice of when to upgrade. AWS's own documentation for Aurora notes that the main user is created without superuser rights and that you cannot reach the host operating system; on self-managed PostgreSQL there is no such limit.

The cost of that control is operations. PostgreSQL's documentation states that it does not provide the software to detect a failed primary and promote a standby, so production clusters add a failover manager such as Patroni, plus backups, monitoring and patching. Our PostgreSQL backup, recovery and high availability guide covers what that involves.

How each is billed

We do not quote cloud prices here; AWS's pricing pages are the source. What differs is the shape of the bill, as AWS documents it.

• RDS for PostgreSQL bills DB instance hours by instance class, provisioned storage per GiB-month, provisioned IOPS per IOPS-month on storage types that use them, I/O requests only on magnetic storage, backup storage, and data transfer out to the internet or other Regions. Reserved instances trade a one- or three-year term for a lower instance rate.
• Aurora PostgreSQL bills instance hours, storage per GiB-month for the space actually used in the cluster volume, backup storage and data transfer. The storage configuration decides I/O charges. Aurora Standard adds a charge per million I/O requests. Aurora I/O-Optimized has no separate charge for read and write I/O; you pay for instances and storage only. AWS lets you move from Standard to I/O-Optimized once every 30 days and back at any time. Aurora Serverless bills in Aurora capacity unit hours, where an ACU is roughly 2 GiB of memory with matching CPU and networking, and capacity scales within a range you set.
• Self-managed PostgreSQL has no licence fee. You pay for the compute and storage you run it on and for the people or support contract that keep it running.

The practical consequence: Aurora's bill depends on your I/O pattern and storage configuration, RDS's on how much storage and IOPS you provision, and self-managed on your own infrastructure and staffing.

The version calendar and Extended Support

PostgreSQL supports each major version for five years. AWS keeps Aurora and RDS major versions in standard support at least until community end of life, then moves remaining clusters into RDS Extended Support, a paid offering that adds fixes for critical and high CVEs for up to three years past community end of life. Charges start the day after standard support ends and stop when you upgrade or delete the database. For PostgreSQL 14, community support ends on 12 November 2026, and standard support on RDS and Aurora runs to 28 February 2027. Our RDS Extended Support cost guide works through what that means for a fleet.

How to choose

• Choose Aurora PostgreSQL when the workload will stay on AWS, read scaling and quick failover matter, and you want variable capacity through Aurora Serverless or cross-Region reads through a global database.
• Choose RDS for PostgreSQL when you want managed operations with community PostgreSQL behaviour and predictable provisioned storage.
• Choose self-managed PostgreSQL when you need superuser access or extensions AWS does not offer, run across several clouds or on premises, want control of the upgrade calendar, or find that managed-service costs no longer match the work they save. Our cloud database repatriation guide explains how to move a live database off RDS or Aurora with logical replication.

Where OSSeva fits

OSSeva supports self-managed PostgreSQL: community builds on your servers, VMs and Kubernetes, in any cloud account. It does not support databases inside Amazon RDS or Aurora, which AWS runs and patches. OSSeva for PostgreSQL ships patched builds for 11, 12, 13 and, from 12 November 2026, 14, supports Patroni and repmgr, and covers estates leaving a managed service, with support from the first day after cutover. See cloud database repatriation and Patroni support, or book a discovery call for a quote.

Frequently asked questions

Postgres Aurora vs RDS: what is the difference?

RDS for PostgreSQL runs community PostgreSQL on instances with their own provisioned storage, with Multi-AZ standbys for failover. Aurora PostgreSQL runs a PostgreSQL-compatible engine on a shared cluster volume with six copies across three Availability Zones, up to 15 replicas that read the same volume, and a different billing model for storage and I/O.

Aurora PostgreSQL vs self-managed PostgreSQL: which should I choose?

Aurora if you are staying on AWS and value managed failover, read scaling and elastic capacity over control. Self-managed if you need superuser access, unrestricted extensions, portability across clouds and data centres, or your own upgrade timetable, and you can staff or contract the operations.

Is Aurora PostgreSQL the same as PostgreSQL?

It is compatible, not the same. Applications connect with PostgreSQL drivers and run PostgreSQL SQL, but Aurora replaces the storage layer and replication, carries its own version numbers and release schedule, and limits superuser access and extensions.

Is Aurora cheaper than RDS?

It depends on the workload, so compare with your own numbers on AWS's pricing pages. RDS bills provisioned storage and IOPS; Aurora bills the storage you use and, on Aurora Standard, each million I/O requests, or no I/O charge on Aurora I/O-Optimized. I/O-heavy workloads and spiky workloads on Aurora Serverless come out differently from steady ones.

Can I migrate from Aurora to self-managed PostgreSQL?

Yes. Aurora PostgreSQL supports logical replication to an external PostgreSQL server once rds.logical_replication is enabled in a custom cluster parameter group, so a large database can be copied while live and cut over in minutes. pg_dump and pg_restore work for smaller databases.

Does Aurora PostgreSQL support all PostgreSQL extensions?

No. You can install the extensions AWS makes available for Aurora PostgreSQL. Extensions outside that list cannot be added, and there is no superuser account or host access to build them yourself.