AWS RDS MySQL vs RDS PostgreSQL

Quick verdict

RDS for MySQL runs Oracle's MySQL Community Edition as a managed service. AWS builds it with AWS-LC (a FIPS 140-3 certified cryptographic library) from 8.4, restricts some server features, and exposes administration through mysql.rds_* stored procedures because there is no host access or full SUPER privilege.

RDS for PostgreSQL runs community PostgreSQL as a managed service, with an rds_superuser role in place of a superuser and a curated list of extensions you can install with CREATE EXTENSION.

Both are RDS engines, so backups, monitoring, parameter groups, Reserved Instances and the console work the same way. This page covers only what changes with the engine on RDS. For Aurora's versions of these engines, see Amazon Aurora vs MySQL and Aurora PostgreSQL vs RDS PostgreSQL.

Side by side

Key differences

Versions offered on RDS

RDS for MySQL has a single major version in standard support: MySQL 8.4, at 8.4.11 since 21 August 2026, supported until 31 July 2029. MySQL 8.0 left RDS standard support on 31 July 2026 and, like 5.7, now runs only under paid RDS Extended Support. Oracle's newer lines (9.5, 9.6, 9.7 LTS and the 26.7 Innovation release) are offered only in the Database Preview environment, where instances and their backups are deleted after 60 days, AWS Support is not available, and snapshots cannot be copied to production. AWS targets only Oracle's LTS majors for production, within 6 months.

RDS for PostgreSQL supports five majors, 14 to 18, with 18.6 the latest minor (25 August 2026). AWS targets new majors within 30 days of the community's first minor and minors within 7 days. PostgreSQL 14 reaches community end of life on 12 November 2026 and RDS end of standard support on 28 February 2027, so plan that upgrade now. In practice, PostgreSQL users can stay on the newest community major in production; MySQL users on RDS cannot use 9.7 LTS in production yet.

Multi-AZ DB clusters behave differently per engine

Multi-AZ DB clusters (a writer plus two readable standbys in three AZs, using semisynchronous replication) are available only for MySQL and PostgreSQL on RDS, on a limited set of instance classes with local NVMe storage such as db.m6gd, db.r6gd and db.r8gd. Region availability is the same for both engines.

Failover differs. AWS documents that for MySQL, failover time depends on the replica lag of both remaining readers, which must apply outstanding transactions before one is promoted; for PostgreSQL it depends on the reader with the lowest lag. Both use flow control to throttle the writer: on MySQL it is on by default through rpl_semi_sync_master_target_apply_lag (120 seconds), and on PostgreSQL it is an extension that adds delay when a reader is more than two minutes behind. MySQL clusters require binlog_format ROW, and AWS strongly recommends a primary key on every table to avoid replication errors.

Extensions versus option-group plugins

RDS for PostgreSQL exposes a long, versioned list of extensions; for PostgreSQL 18 it includes pgvector 0.8.2, PostGIS 3.6.3, pg_cron, pg_partman, pg_repack, pg_hint_plan, pgAudit, orafce and pgactive. Trusted Language Extensions (pg_tle) let you write your own extensions in SQL, PL/pgSQL, JavaScript, Perl or Tcl without file system access.

RDS for MySQL is far narrower. Its option groups offer two options: the MariaDB Audit Plugin (including 8.4) and memcached (5.7 and 8.0 only; it is gone in 8.4). AWS lists MySQL features RDS does not support, including the X Plugin, the password strength and authentication plugins, the Rewriter query rewrite plugin, InnoDB tablespace encryption, persisted system variables and transportable tablespaces. InnoDB is the only engine for which point-in-time and snapshot restore are reliable. On the plus side, RDS for MySQL 8.4 and 8.0.35 and higher support the Group Replication plugin for active-active clusters.

Day-to-day administration looks different as a result:

-- RDS for MySQL: settings through RDS stored procedures
CALL mysql.rds_set_configuration('binlog retention hours', 24);

-- RDS for PostgreSQL: features through extensions
SELECT name, default_version FROM pg_available_extensions WHERE name = 'vector';
CREATE EXTENSION vector;

Blue/Green Deployments: binlog versus logical replication

Both engines support Blue/Green Deployments for upgrades and changes, with shared limits: no Multi-AZ DB cluster deployments, cascading or cross-Region read replicas, or Secrets Manager-managed master passwords; zero-ETL integrations must be removed before switchover; and point-in-time recovery history does not carry over to the new production instance.

MySQL Blue/Green uses binary log replication. Its specific limits are short: the blue instance cannot be an external binlog replica, a custom option group prevents specifying the major upgrade at creation (you upgrade the green side afterwards), and the AWS JDBC Driver for MySQL is not supported.

PostgreSQL uses physical replication unless you upgrade the major version, when it switches to logical replication, and the restrictions grow. DDL such as CREATE TABLE is not replicated and puts the green side into a "Replication degraded" state that requires recreating the deployment; large objects have the same effect; sequences are only synchronised at switchover; materialized views are not refreshed; tables without a primary key cannot take UPDATE or DELETE; pg_partman, pglogical and pgactive must be disabled; and the apply process is single-threaded, so AWS suggests AWS DMS for very write-heavy major upgrades.

Zero-ETL integrations to Redshift and SageMaker

Both engines can feed Amazon Redshift or an Amazon SageMaker lakehouse through managed zero-ETL integrations (up to five per source instance by default), and in both, DDL on a source table can trigger a table resynchronisation. RDS for MySQL integrations read the binlog, accept a Multi-AZ DB cluster as the source, work only with InnoDB tables, and reject cascading foreign key actions (ON DELETE or ON UPDATE CASCADE, SET NULL, SET DEFAULT).

RDS for PostgreSQL integrations need 15.7, 16.3, 17.1 or later, cannot use a Multi-AZ DB cluster or a read replica as the source, do not replicate unlogged tables, materialized views, geometric types or values over 64 KB, and block major version upgrades while the integration exists. Declarative partitioning transactions on the source put the affected tables into a failed state. If analytics replication is central to your design, MySQL currently has fewer restrictions on RDS.

Security and monitoring: mostly identical

IAM database authentication works with MySQL, MariaDB and PostgreSQL, using tokens valid for 15 minutes, and AWS advises 300 to 1,000 MiB of spare memory on the instance. PostgreSQL has two specifics: granting rds_iam to a user makes IAM take precedence over the password, and IAM and Kerberos cannot be enabled together. RDS for MySQL 8.4 defaults to caching_sha2_password and supports TLS 1.2 and 1.3 only.

Monitoring is the same for both: Performance Insights reached end of life on 31 July 2026 and is replaced by CloudWatch Database Insights, alongside Enhanced Monitoring and CloudWatch Logs. For third-party options, see the MySQL monitoring tools and PostgreSQL monitoring tools guides.

Pricing and licensing

RDS bills both engines the same way: instance-hours (On-Demand or Reserved), allocated storage per GB-month by volume type, provisioned IOPS and throughput above the gp3 baseline, backup storage beyond the free allowance, and data transfer. Neither engine has a licence fee.

The instance rates are identical. In AWS's published On-Demand prices for US East (N. Virginia) in October 2026, in USD, a db.m7g.large is 0.168 per hour Single-AZ and 0.337 per hour as a Multi-AZ DB instance, and a db.r7g.large is 0.239 per hour Single-AZ, for both RDS for MySQL and RDS for PostgreSQL. Costs diverge only through what you run: MySQL 8.0 and 5.7 now incur RDS Extended Support charges, and PostgreSQL 14 will after 28 February 2027. Use the AWS Pricing Calculator for your Region and configuration.

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 need shared-storage replicas, Serverless v2 or Aurora-only features: see Amazon RDS vs Amazon Aurora.
• You want serverless Postgres with branching: see Neon vs AWS RDS, or a full backend platform: Supabase vs AWS RDS.
• You are choosing a cloud, not an engine: see AWS RDS vs Google Cloud SQL.

Final recommendation

Frequently asked questions

Sources

• Amazon RDS User Guide: MySQL on Amazon RDS versions (incl. Database Preview environment)
• RDS for PostgreSQL release calendars
• Amazon RDS User Guide: Multi-AZ DB cluster deployments
• Amazon RDS User Guide: Supported Regions and engines for Multi-AZ DB clusters
• Amazon RDS User Guide: MySQL feature support on Amazon RDS
• Amazon RDS User Guide: Options for MySQL DB instances
• RDS for PostgreSQL extension versions
• Amazon RDS User Guide: Limitations for blue/green deployments
• Amazon RDS User Guide: Zero-ETL integrations
• Amazon RDS User Guide: IAM database authentication
• Amazon RDS User Guide: Active-active clusters for RDS for MySQL
• Amazon RDS for MySQL pricing
• Amazon RDS for PostgreSQL pricing

Checked October 2026.

How we research comparisons: our editorial method.