MySQL 8.0 End of Life (April 30, 2026): RDS Extended Support Since August 1 (About $146 a Month), Aurora MySQL 3 Until 2028, and a Tested Upgrade to 8.4

MySQL 8.0 reached end of life on April 30, 2026. The community has stopped releasing 8.0 versions; 8.0.46 was the last. On Amazon RDS for MySQL, 8.0 left standard support on July 31, 2026, and every RDS MySQL 8.0 instance has been in paid RDS Extended Support since August 1, 2026: $0.10 per vCPU-hour, about $146 a month for a 2-vCPU instance, doubling from August 1, 2028. Aurora MySQL version 3 (also MySQL 8.0) is different: it keeps standard support until April 30, 2028. Upgrade to MySQL 8.4 LTS. Test first, because in our 8.0.46 to 8.4.11 upgrade, a single stored procedure containing SHOW SLAVE STATUS made the upgrade abort ("Data Dictionary initialization failed"), and users with mysql_native_password could no longer log in to community 8.4 ("Plugin 'mysql_native_password' is not loaded").

Ethan noticed it on the October bill: a new line, "Extended Support for MySQL 8", on the shop's old analytics database. It had been there since August. "We never turned anything on," he said. "That's the point," Jake said. "You never turned anything off either."

This guide explains what MySQL 8.0's end of life means on your own servers, on Amazon RDS and on Aurora; what Extended Support costs; which version to move to; and how to upgrade to 8.4 without the surprises we hit. We upgraded a MySQL 8.0.46 data directory in place to 8.4.11 several times, each with a different problem planted in it, and recorded exactly what each version said.

MySQL 8.0 end of life: the dates

• April 30, 2026: community end of life. MySQL 8.0 receives no more community releases; 8.0.46 was the final one.
• July 31, 2026: end of RDS standard support. RDS for MySQL 8.0 is now only available under Extended Support.
• August 1, 2026: Extended Support year 1 pricing started for every RDS for MySQL 8.0 instance. RDS keeps shipping patched builds under it, such as 8.0.46-RDS.20260908, with critical security and bug fixes.
• August 1, 2028: year 3 pricing, double the rate.
• July 31, 2029: end of Extended Support. After that, RDS upgrades remaining 8.0 instances automatically.
• Aurora MySQL version 3 (MySQL 8.0 compatible): standard support until April 30, 2028, Extended Support from May 1, 2028 to July 31, 2029.

So "is MySQL 8.0 end of life?" Yes, since April. "Is it still supported on AWS?" Yes, but on RDS you have been paying for that support since August 1 unless you opted out, and on Aurora it is free for another 18 months.

MySQL end-of-life dates (5.7, 8.0, 8.4 and the new LTS)

Two naming changes trip people up. Aurora numbers its versions separately (Aurora MySQL 2 is 5.7-compatible, 3 is 8.0-compatible, and the newest is called Aurora MySQL 8.4). And MySQL itself switched to calendar version numbers after 9.7 LTS: 26.7, released in July 2026, means 2026, July. It is an "Innovation" release with a short life, not an LTS.

What end of life means for a MySQL 8.0 server you run yourself

Your server keeps running. Nothing turns off on April 30. What stops is maintenance:

• No more security fixes. Vulnerabilities found from now on get fixed in 8.4 and 9.x, not in 8.0.
• No more bug fixes, including crash and replication fixes.
• Distribution packages and the mysql:8.0 image freeze at 8.0.46. The Docker image we pulled this week reported exactly that version.
• Applications move on. Frameworks, drivers and hosting control panels gradually stop testing against 8.0.
• Audits flag it. Unsupported database software is a standard finding in security reviews.

If you run MySQL on EC2, in Docker or on a VPS, the fix is an upgrade you do yourself. If you run it on RDS, AWS has been patching it for you, for a fee, and the next section is about that fee.

What RDS Extended Support for MySQL 8.0 costs

Extended Support is charged per vCPU-hour on top of the normal instance price, on every instance, whether it is busy or idle. US East (N. Virginia) rates:

RDS for MySQL 8.0, years 1-2 (Aug 1, 2026 - Jul 31, 2028):  $0.10 per vCPU-hour
RDS for MySQL 8.0, year 3   (Aug 1, 2028 - Jul 31, 2029):  $0.20 per vCPU-hour
Aurora Serverless v2, Aurora MySQL 3 (from May 1, 2028):    $0.085 per ACU-hour

db.t4g.micro / db.t3.micro (2 vCPUs):  2 x $0.10 x 730 h = $146.00 a month  (year 3: $292.00)
db.r6g.large (2 vCPUs):                2 x $0.10 x 730 h = $146.00 a month  (year 3: $292.00)
db.r6g.2xlarge (8 vCPUs):              8 x $0.10 x 730 h = $584.00 a month  (year 3: $1,168.00)

The micro instance is the painful one: the Extended Support charge is several times the instance's own price, which is how a "free tier" database ends up costing $146 a month. It appears on the bill as a separate RDS line naming Extended Support for MySQL 8, so search the bill for "Extended Support" first.

Find every affected instance, in every Region you use:

aws rds describe-db-instances \
  --query "DBInstances[?Engine=='mysql' && starts_with(EngineVersion,'8.0')].[DBInstanceIdentifier,EngineVersion,DBInstanceClass,EngineLifecycleSupport]" \
  --output table

Setting EngineLifecycleSupport to open-source-rds-extended-support-disabled on an instance that is already past standard support does not just stop the charge: it starts the upgrade to the next supported major version. Use it on a test database you are happy to see upgraded, not on production you have not tested.

Aurora MySQL 3 vs RDS for MySQL 8.0: same engine, different deadline

This is the most surprising part of the calendar. Both run MySQL 8.0, but:

• RDS for MySQL 8.0 follows the community version: standard support ended July 31, 2026, three months after the community end of life.
• Aurora MySQL version 3 is AWS's own engine, compatible with MySQL 8.0, and AWS supports it on its own schedule: standard support until April 30, 2028, 21 months later than RDS.

That does not mean you should move to Aurora just to dodge the fee. Aurora prices storage and I/O differently and usually costs more for small databases, as the RDS vs Aurora cost comparison shows. But if you were already considering Aurora, the support dates are one more point in its favor. If you are on Aurora MySQL 3, you are fine until 2028; plan the move to Aurora MySQL 8.4 calmly over the next year.

"So should we move the analytics database to Aurora to save the $146?" Ethan asked. Jake did the sum on the back of the bill. "Upgrading to 8.4 saves the $146 and costs us an afternoon. Moving to Aurora costs more every month to avoid an afternoon."

Which version should you upgrade MySQL 8.0 to?

MySQL 8.4 LTS. It is the long-term support release that follows 8.0, it is generally available on RDS and Aurora, and it is supported until April 2029 in the community (July 2029 in RDS standard support). It is also the only allowed next step: MySQL does not support skipping a major release, so even if you want 9.7 eventually, you go 8.0, then 8.4, then 9.7.

• 9.7 LTS (April 2026) is the newer long-term release, but on RDS it is only in the Database Preview Environment. Plan it as your next upgrade, not this one.
• 9.5, 9.6 and 26.7 are Innovation releases with short support windows. They are for testing new features, not for production you want to leave alone.
• MariaDB is a different database that forked from MySQL long ago. It is not an upgrade path, and moving to it is a migration with its own testing.

On RDS, a direct upgrade from 8.0 to 8.4 needs 8.0.22 or later; older 8.0 minor versions must first move to a newer 8.0 release.

What breaks from MySQL 8.0 to 8.4 (tested)

We created a database on 8.0.46 with the usual habits of an older application, then started an 8.4.11 server on the same data directory. Here is what each habit did:

The successful in-place upgrade logged two steps, "Data dictionary upgrading from version '80023' to '80300'" and "Server upgrade from '80046' to '80411'", and took about a minute and a half on a small test database. Large databases with many tables take longer, mostly in the second step.

The upgrade that aborts: SLAVE and MASTER in stored procedures

MySQL 8.4 removed the old replication statements that used "master" and "slave" (renamed to "source" and "replica" over the 8.0 releases). That sounds like a syntax change you fix later. It is not, because the 8.4 server re-parses every stored routine while upgrading the data dictionary. We created two procedures on 8.0:

DELIMITER //
CREATE PROCEDURE ops.replica_lag()  BEGIN SHOW SLAVE STATUS; END//
CREATE PROCEDURE ops.restart_repl() BEGIN STOP SLAVE; START SLAVE; END//
DELIMITER ;

Then started 8.4.11 on that data. It refused to start:

[ERROR] [MY-013235] [Server] Error in parsing Routine 'ops'.'replica_lag' during upgrade.
  You have an error in your SQL syntax; ... near 'slave status; end' at line 2
[ERROR] [MY-013235] [Server] Error in parsing Routine 'ops'.'restart_repl' during upgrade.
  ... near 'slave; start slave; end' at line 2
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
[ERROR] [MY-010119] [Server] Aborting

The good news: the 8.0 server started normally on the same data afterwards, so nothing was lost. We rewrote the procedures with the new words, which 8.0.22 and later already accept, and the upgrade then completed:

-- run on 8.0 BEFORE upgrading: find routines that mention the old words
SELECT routine_schema, routine_name
FROM information_schema.routines
WHERE LOWER(routine_definition) REGEXP 'slave|master'
  AND routine_schema NOT IN ('mysql', 'sys');

-- old                      new (first version that accepts the new form)
-- SHOW SLAVE STATUS        SHOW REPLICA STATUS            (8.0.22)
-- START SLAVE / STOP SLAVE START REPLICA / STOP REPLICA  (8.0.22)
-- CHANGE MASTER TO         CHANGE REPLICATION SOURCE TO   (8.0.23)
-- SHOW MASTER STATUS       SHOW BINARY LOG STATUS         (8.2; on 8.0 leave it out of routines)

Note the LOWER(): the routine text is compared case-sensitively, and in our test a plain REGEXP 'slave' missed a routine written in capitals. Check triggers (information_schema.triggers.action_statement) and events (information_schema.events.event_definition) the same way. On RDS, the upgrade pre-check tries to find these routines for you and stops the upgrade before it starts, but its list may not be complete; run the query anyway. RDS's own replication procedures have new names in 8.4 too (for example mysql.rds_set_external_source instead of rds_set_external_master), and both names work for now.

mysql_native_password in 8.4: ERROR 1524 and how RDS differs

Older applications and drivers often use accounts created with mysql_native_password. In community MySQL 8.4 that plugin still ships but is disabled by default. After our upgrade, the old account failed and the new one worked:

$ mysql -h 127.0.0.1 -u legacyapp -p
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

$ mysql -h 127.0.0.1 -u newapp -p        # created with the default plugin
mysql> SELECT current_user();            -- newapp@%

Two fixes, both tested:

1. Convert the account (the real fix): ALTER USER 'legacyapp'@'%' IDENTIFIED WITH caching_sha2_password BY '...';. After that the account logged in on a default 8.4 server. If your driver then fails with "caching_sha2_password cannot be loaded", the driver is too old; the caching_sha2_password guide lists the fixes per language.
2. Turn the old plugin back on as a bridge: start the server with --mysql-native-password=ON (or mysql_native_password=ON in my.cnf). The old login worked again, and the server logged that the plugin "is deprecated and will be removed in a future release". It is gone entirely in 9.x, so this only buys time.

Do not carry default_authentication_plugin=mysql_native_password over from an 8.0 my.cnf: 8.4 removed that variable, and the server refused to start with "unknown variable 'default-authentication-plugin=mysql_native_password'".

On RDS it is gentler. RDS for MySQL 8.4 makes caching_sha2_password the default for new users, but after an in-place upgrade from 8.0 your existing users, including the primary (master) user, keep using mysql_native_password and keep working. Convert them anyway, because 9.7 will not have the plugin at all. List them with SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';.

Defaults that change on RDS for MySQL 8.4

If you upgrade on RDS with a new default parameter group, several InnoDB defaults change. These matter for performance testing, because your 8.4 copy will not behave exactly like your 8.0 production:

• innodb_adaptive_hash_index: ON in 8.0, OFF in 8.4.
• innodb_change_buffering: ALL in 8.0, NONE in 8.4.
• innodb_io_capacity: 200 in 8.0, 10000 in 8.4.
• innodb_log_buffer_size: 16 MB in 8.0, 64 MB in 8.4.
• innodb_read_io_threads, innodb_buffer_pool_instances and innodb_page_cleaner_threads now scale with the instance's CPUs and memory.
• temptable_max_ram: 1 GB in 8.0, 3% of memory (1 to 4 GiB) in 8.4; temptable_use_mmap goes from ON to OFF.
• restrict_fk_on_non_standard_key is new and ON, which is why new foreign keys on non-unique keys fail.
• binlog_transaction_dependency_tracking is removed; 8.4 always uses write sets.

Copy your custom 8.0 parameters into a new mysql8.4 family parameter group and review each one against this list before the upgrade. Parameter changes that need a reboot will show as pending until you reboot, as the pending-reboot guide explains.

Upgrading RDS for MySQL 8.0 to 8.4, step by step

1. Inventory: run the instance query above in every Region, and note which instances are paying Extended Support today.
2. Scan each database for SLAVE/MASTER in routines, triggers and events, for mysql_native_password users, and for foreign keys on non-unique keys.
3. Create a mysql8.4 parameter group with your custom settings carried over and reviewed.
4. Test on a copy: restore a snapshot to a new instance, upgrade it to 8.4, and run your application's tests and slowest queries. If the pre-check stops the upgrade, the instance's events and logs name the objects that failed.
5. Upgrade production with a Blue/Green Deployment, the lowest-risk option for this upgrade: the green copy on 8.4 stays in sync with production, you test it, then switch over.

   aws rds create-blue-green-deployment --blue-green-deployment-name analytics-to-84 \
     --source arn:aws:rds:us-east-1:111122223333:db:analytics-db \
     --target-engine-version 8.4.11 --target-db-parameter-group-name analytics-mysql84

   For a small database that can be offline for a few minutes, an in-place upgrade (aws rds modify-db-instance ... --engine-version 8.4.11 --allow-major-version-upgrade --apply-immediately) is simpler.
6. After the switch, convert remaining mysql_native_password users, update scripts that call RDS replication procedures by their old names, and check that the Extended Support line disappears from the next bill.

Use the newest 8.4 minor version available in your Region in place of 8.4.11. If replicas lag after the switch while caches warm up, the replica lag guide covers what to check.

Upgrading a self-managed or Docker MySQL 8.0 to 8.4

On your own servers, an in-place upgrade is supported from 8.0 to 8.4: stop 8.0 cleanly, start the 8.4 binaries on the same data directory, and the server upgrades the data dictionary and system tables on first start. That is exactly what we did with the Docker images (mysql:8.0 then mysql:8.4 on the same volume). The safe order:

1. Take a full backup (mysqldump --all-databases --routines --events --triggers, or a filesystem snapshot with the server stopped) and confirm you can restore it.
2. Run the scans from the procedure and authentication sections on the 8.0 server, and fix what they find while you are still on 8.0.
3. Remove options 8.4 does not know from my.cnf, starting with default_authentication_plugin; an unknown option stops the server.
4. Stop 8.0 cleanly, start 8.4, and watch the error log until "Server upgrade from '80046' to '804xx' completed" and "ready for connections".
5. If it aborts, read the error lines above "Aborting", start 8.0 again on the same data (it worked in our test after a failed attempt), fix the named objects, and try again.

Package managers make the binary swap for you. On Amazon Linux 2023 the MySQL community repository decides which major version you get, which the MySQL install guide walks through. If a restored dump complains about a definer that does not exist, the ERROR 1449 guide has the fix.

Ethan ran the procedure query on the analytics database before anything else. It found one routine, a nightly check Jake had written years ago that ran SHOW SLAVE STATUS to email the replica lag. "That would have stopped the whole upgrade," Ethan said. Jake rewrote it in two minutes and admitted he had forgotten it existed. "That's why we ask the database," he said, "and not my memory."

Errors you may hit upgrading MySQL 8.0 to 8.4

[ERROR] [MY-013235] Error in parsing Routine ... during upgrade

A stored routine uses syntax 8.4 removed, usually SLAVE/MASTER replication statements. Start 8.0 again, rewrite the routine with REPLICA/SOURCE terms, and repeat the upgrade.

[ERROR] [MY-010020] Data Dictionary initialization failed

Read the lines just above it; they name the routine, trigger, event or table that failed to upgrade. The data is not converted at that point, so 8.0 can start on it again.

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

The account uses the old plugin, which community 8.4 disables by default. Convert it with ALTER USER ... IDENTIFIED WITH caching_sha2_password, or start the server with --mysql-native-password=ON for now.

unknown variable 'default-authentication-plugin=mysql_native_password'

An 8.0 option left in my.cnf. Remove it; 8.4 uses authentication_policy instead, and its default is already caching_sha2_password.

ERROR 6125: Failed to add the foreign key constraint. Missing unique key

A new foreign key points at a column that is not unique. Add a unique key on the referenced column; SET restrict_fk_on_non_standard_key = OFF allows it temporarily, with a deprecation warning.

ERROR 1064 near 'slave status' or 'master status'

Typed or scripted replication commands using the removed words. Use SHOW REPLICA STATUS and SHOW BINARY LOG STATUS.

My RDS bill has a new "Extended Support" line for MySQL 8

The instance is still on MySQL 8.0, which has been billed for Extended Support since August 1, 2026. Upgrade it to 8.4 to stop the charge.

Frequently asked questions

The analytics database moved to 8.4 on a Sunday through Blue/Green, and the next bill had no Extended Support line. Ethan converted the last two old-style users the same week. Jake added one line to the team wiki under "Before any MySQL upgrade": run the routine query. Then he added a second line under it: "And read the error log above the word Aborting."

Revision note. Written October 23, 2026. "Forewarned is forearmed," the proverb says; one query before the upgrade is worth an evening of reading error logs after it.