Amazon Aurora vs MySQL: Versions, Differences (2026)

Quick verdict

Short answer

Choose Aurora MySQL if you are committed to AWS and want MySQL-compatible SQL with Aurora's shared multi-AZ storage, up to 15 low-lag replicas, Serverless v2 capacity, fast clones and Backtrack. Choose community MySQL (self-managed, or on Amazon RDS for MySQL if you want it managed) if you need behaviour identical to upstream MySQL, a version Aurora does not offer yet, features Aurora omits (such as the X plugin, multisource replication or multi-factor authentication), or the freedom to move between clouds without rework.

How we know: This comparison is research-based: version mappings, release dates, feature differences, migration paths and prices were checked against the Amazon Aurora User Guide, the Aurora MySQL release notes and release calendar, the Amazon RDS for MySQL version documentation and AWS pricing pages in October 2026. We have not run performance tests.

Amazon Aurora MySQL-Compatible Edition is a managed engine that speaks the MySQL protocol and SQL dialect but stores data in Aurora's distributed cluster volume, replicated across three Availability Zones and shared by every instance in the cluster. It runs only on AWS. AWS currently supports two production major versions: Aurora MySQL version 3, compatible with MySQL 8.0 (3.13, released 27 August 2026, is compatible with community MySQL 8.0.45), and Aurora MySQL version 8.4, compatible with MySQL 8.4 (8.4.7 on 21 May 2026, then 8.4.8 on 3 September 2026, compatible with community 8.4.8). Version 2 (MySQL 5.7) is only available under paid RDS Extended Support.

MySQL here means the community server from Oracle, licensed under GPLv2, which you can run on your own hardware, on any cloud VM, or as Amazon RDS for MySQL. MySQL now uses calendar versioning: 8.4 and 9.7 are the LTS lines and 26.7 is the current Innovation release. RDS for MySQL supports 8.4 in production (8.4.11 since 21 August 2026); 8.0 is now available only under RDS Extended Support, and 9.5, 9.6, 9.7 and 26.7 are offered only in the RDS Database Preview environment, which is not for production use.

For the wider RDS-versus-Aurora decision, including PostgreSQL, see Amazon RDS vs Amazon Aurora. For MySQL against its fork, see MariaDB vs MySQL.

Side by side

Aspect	Amazon Aurora	MySQL
What it is	AWS-only managed engine, MySQL-compatible	Open source server (GPLv2); self-managed anywhere or managed on RDS for MySQL
Versions available	Aurora MySQL 8.4 (MySQL 8.4) and version 3 (MySQL 8.0); no 9.x or 26.x	8.4 LTS, 9.7 LTS and 26.7 Innovation from Oracle; RDS: 8.4 in production, 9.x and 26.7 in preview only
Storage	Shared cluster volume across three AZs, grows automatically, billed on use	Local or block storage per server; on RDS, EBS volumes you allocate
Replication	Up to 15 Aurora Replicas on shared storage; binlog replication in and out also supported	Binary log replication, Group Replication, multisource replication (self-managed)
Privileges	No SUPER; rds_superuser_role; mysql system tables cannot be modified directly	Full root access when self-managed; managed services such as RDS for MySQL apply their own restrictions
Features missing vs upstream	X plugin, multisource replication, resource groups, user-defined undo tablespaces; MFA on 8.4	None (it is the upstream)
AWS-only extras	Backtrack, copy-on-write clones, Global Database, Serverless v2, LOAD FROM S3, Lambda and ML integration roles	Not available
Portability	Data exports with mysqldump/MySQL Shell or binlog replication; Aurora-specific features need rework	Runs on any platform or cloud
Main trade-off	AWS-native availability and scaling, but a later version cadence and documented differences	Newest versions and full control, but you (or RDS) provide the HA design

Key differences

Version compatibility and lag

Aurora MySQL publishes a version currency policy: new Aurora major versions arrive "within 12 months" of the community's first minor release of an Oracle MySQL LTS major, and minor versions within 3 months of the community release. RDS for MySQL targets LTS majors within 6 months and minors within 30 days. MySQL 8.4 shows the gap in practice: Oracle released it on 30 April 2024, RDS for MySQL added it on 21 November 2024, and Aurora MySQL 8.4 arrived on 21 May 2026.

Because Aurora tracks LTS majors only, it does not offer MySQL 9.x Innovation releases or the 26.x line, and AWS has not published an Aurora version for MySQL 9.7 LTS. Aurora also changed its numbering with 8.4: version 3 releases carried names such as 8.0.mysql_aurora.3.04.1, while 8.4 uses a simpler 8.4.7-style number. For support windows, AWS lists Aurora MySQL version 3 in standard support until 30 April 2028 (MySQL 8.0 reached community end of life in April 2026) and Aurora MySQL 8.4 until April 2032; RDS for MySQL lists 8.4 standard support until 31 July 2029.

Documented feature differences

AWS states that Aurora MySQL version 3 "in general" supports the feature set of community MySQL 8.0.23, and lists features that are unavailable or work differently: resource groups, user-defined undo tablespaces, the X plugin and multisource replication are not supported, and you cannot change the settings of MySQL plugins. You cannot modify tables in the mysql schema directly (create users with CREATE USER and roles instead), and the administrative user receives rds_superuser_role rather than full SUPER. Version 3 keeps mysql_native_password as the default authentication plugin, and the default cannot be changed.

For Aurora MySQL 8.4, AWS documents that authentication_policy accepts only two single-factor values (multi-factor authentication is not supported), that mysql_native_password stays enabled and cannot be disabled (community 8.4 disables it by default), that the validate_password component is managed through a parameter, that automatic histogram updates are disabled from 8.4.7, and that memory-mapped temporary tables stay enabled by default. AWS also notes that the Aurora "fast insert" optimisation is not available in 8.4.

Small things differ too. Finding the server identity, for example:

-- Community MySQL: numeric server ID
SELECT @@server_id;

-- Aurora MySQL: the DB instance identifier
SELECT @@aurora_server_id;

What Aurora adds

The reasons to accept those differences are architectural. Aurora's cluster volume keeps copies across three AZs regardless of instance count, readers attach to the same storage (AWS documents replica lag as usually well under 100 milliseconds), and a replica is promoted automatically if the writer fails. On top of that, Aurora MySQL offers features community MySQL does not have: Backtrack rewinds a whole cluster to an earlier point within a window of up to 72 hours (it must be enabled at creation and is offered only in some Regions); copy-on-write clones create test copies without copying data; Global Database adds up to 10 secondary Regions; and Aurora Serverless v2 scales compute between 0 and 256 ACUs.

Aurora MySQL also integrates with other AWS services through built-in roles such as AWS_LOAD_S3_ACCESS (for LOAD DATA FROM S3), AWS_SELECT_S3_ACCESS, AWS_LAMBDA_ACCESS and roles for Amazon Bedrock, SageMaker and Comprehend. These are useful, and they are also the parts of an application that will not run on any other MySQL.

Migration paths and lock-in

Getting into Aurora is well documented. From RDS for MySQL you can create an Aurora read replica of the instance and promote it when lag reaches zero, or migrate directly from an RDS snapshot. From MySQL outside RDS you can load a logical dump (mysqldump or MySQL Shell's dump utilities, which AWS suggests for exporting user metadata), restore a physical Percona XtraBackup copy from Amazon S3 (subject to InnoDB file-layout requirements), or load text files with LOAD DATA FROM S3. AWS notes that some early 8.0 versions (8.0.11, 8.0.13, 8.0.15) cannot be migrated to Aurora MySQL 3.05 and higher directly.

Getting out is also possible because the data and SQL are MySQL: Aurora MySQL supports binary log replication with Aurora as the source or the target, and logical dumps restore into community MySQL. In our assessment, the lock-in is less about data and more about operations: Backtrack, cloning, Global Database, Serverless scaling, S3 and Lambda calls, and Aurora-specific parameters all have to be replaced with your own tooling if you leave AWS.

Pricing and licensing

Community MySQL is free to use under GPLv2; Oracle sells commercial editions separately. Running it yourself costs whatever the servers, storage, backups and staff time cost. Amazon RDS for MySQL is billed per instance-hour (On-Demand or Reserved), per GB-month of allocated storage by type, plus provisioned IOPS, backup storage and data transfer; Multi-AZ adds standby instances. Use the AWS Pricing Calculator for your Region and instance class.

Aurora MySQL is billed per instance-hour or per ACU-hour for Serverless v2, plus storage used and, on the Aurora Standard configuration, I/O requests. As one example, listed on the Aurora pricing page in October 2026 for US East (N. Virginia): Aurora Standard storage is 0.10 USD per GB-month plus 0.20 USD per million I/O requests, while Aurora I/O-Optimized storage is 0.225 USD per GB-month with no I/O charges. AWS advises I/O-Optimized when I/O is 25% or more of the Aurora bill. Running an Aurora major version past its end of standard support incurs RDS Extended Support charges.

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

Where each one leads

Amazon Aurora strengths

Storage replicated across three AZs and shared by up to 15 replicas
Automatic replica promotion on failover and Global Database across up to 10 Regions
Backtrack, copy-on-write clones and Serverless v2 have no community MySQL equivalent
Now offers MySQL 8.4 compatibility (Aurora MySQL 8.4) alongside version 3
Fully managed patching, backups and storage growth

MySQL strengths

The upstream engine: every MySQL feature, plugin and setting is available when self-managed
Newest releases (9.7 LTS, 26.7 Innovation) available immediately when self-managed
Runs on any hardware, cloud or container platform; GPLv2 licence
Amazon RDS for MySQL offers a managed path that adopts new versions sooner than Aurora

Limitations

Amazon Aurora limitations

Runs only on AWS, and Aurora-specific features do not transfer elsewhere
New MySQL LTS majors arrive up to 12 months after the community (8.4 took about two years)
No 9.x or 26.x versions, and no X plugin, multisource replication or MFA
Restricted privileges: no direct changes to the mysql schema, no full SUPER
Pricing needs care: I/O charges on Aurora Standard and paid Extended Support for old majors

MySQL limitations

Self-managed MySQL leaves high availability, backups and patching to you
MySQL 8.0 reached community end of life in April 2026; staying on it means paying for extended support somewhere
On RDS for MySQL, storage and read replicas are per instance rather than shared
Innovation releases have short support windows and are not offered for production on RDS

When to choose each

Choose Amazon Aurora if

Your application is on AWS for the long term and MySQL-compatible SQL is enough
You need several read replicas with automatic failover and little replication lag
You want serverless capacity that can pause when idle
Fast clones of production data for testing, or Backtrack for undoing mistakes, are valuable to you

Choose MySQL if

You need behaviour identical to upstream MySQL, or a feature Aurora omits
You want MySQL 9.7 LTS or the 26.x Innovation line
You run on several clouds or on-premises and want one engine everywhere
You want MySQL managed on AWS without Aurora's differences: choose RDS for MySQL

When neither is right

You are open to PostgreSQL: Aurora PostgreSQL, RDS for PostgreSQL or a serverless option may fit better; see MySQL vs PostgreSQL.
You want MySQL with built-in horizontal sharding (Vitess) rather than a single writer: see Neon vs PlanetScale.
You prefer an open fork with its own feature set: see MariaDB vs MySQL.

Final recommendation

Bottom line

Aurora MySQL is a good fit when AWS is your long-term platform and you value its storage-level replication, replicas, serverless option and recovery features more than exact upstream behaviour. Community MySQL remains the right base when you need the newest versions, every upstream feature, or freedom to move. Many teams on AWS will find RDS for MySQL the middle path: managed, closer to upstream and quicker to adopt new versions. Whichever you choose, check AWS's documented differences for the exact Aurora version against your application before migrating.

Frequently asked questions

Is Aurora MySQL the same as MySQL?

No. AWS describes it as compatible with MySQL Community Edition (8.0 for version 3, 8.4 for version 8.4), but it is a separate AWS engine on different storage. AWS documents features that are missing or behave differently, such as the X plugin, multisource replication, resource groups and restricted privileges.

Which MySQL version does Aurora MySQL support?

Aurora MySQL version 3 is compatible with MySQL 8.0 (3.13 matches community 8.0.45), and Aurora MySQL version 8.4 is compatible with MySQL 8.4 (8.4.8 matches community 8.4.8, released 3 September 2026). Version 2 (MySQL 5.7) is only under paid Extended Support.

Does Aurora support MySQL 8.4 or 9.x?

Aurora supports MySQL 8.4 through Aurora MySQL version 8.4, first released on 21 May 2026. It does not offer MySQL 9.x or 26.x; Aurora tracks Oracle's LTS major versions. RDS for MySQL offers 9.5 to 9.7 and 26.7 only in its non-production Database Preview environment.

Can I migrate from Aurora back to MySQL?

Yes. You can use binary log replication with Aurora as the source, or take a logical dump with mysqldump or MySQL Shell and load it into community MySQL. Code that relies on Aurora-only features, such as LOAD DATA FROM S3, Lambda calls or Backtrack, has to be replaced.

Should I use Aurora MySQL or RDS for MySQL?

Use RDS for MySQL if you want behaviour closest to upstream, earlier access to new versions and simpler pricing. Use Aurora MySQL if you need shared-storage replicas, Serverless v2, cloning or Global Database. See Amazon RDS vs Amazon Aurora for more detail.

Sources

Checked October 2026.

How we research comparisons: our editorial method.