RDS MySQL 8.0 Is on the Meter. MariaDB Has No Meter to Get On.

If you run Amazon RDS for MySQL 8.0, the charge already started. RDS end of standard support for MySQL 8.0 was 31 July 2026, and per AWS’s release calendar year-one Extended Support pricing began the next day. Nothing shut off. A line item appeared.

That is the usual shape of these deadlines and it is the easy case, because paying is an option. The harder case is the engine where paying is not an option, and most write-ups about RDS deprecation never mention it. Extended Support exists for RDS for MySQL and RDS for PostgreSQL only. MariaDB is not on the list, is not in the price list, and does not get a paid grace period. Prices and dates below came off AWS’s own docs and the us-east-1 price list file on 22 August 2026.

What the MySQL meter costs

Extended Support is billed per vCPU per hour, not per instance and not per GB. From AWS’s us-east-1 price list, effective 1 August 2026:

Engine	Years 1 and 2	Year 3
RDS for MySQL 8.0	$0.10 per vCPU-hour	$0.20 per vCPU-hour
RDS for PostgreSQL 11 to 13	$0.10 per vCPU-hour	$0.20 per vCPU-hour
Aurora Serverless v2	$0.085 per ACU-hour	$0.17 per ACU-hour

Put real numbers on it. A db.m6i.xlarge is 4 vCPUs, and a month is about 730 hours: 4 × $0.10 × 730 comes to roughly $292 a month on top of your normal RDS bill. AWS’s charges page states that Extended Support charges apply to standby instances in Multi-AZ deployments, so a Multi-AZ pair of that size is about $584 a month, and about $1,168 once year-three pricing starts on 1 August 2028.

The year-three step is not theoretical. Anyone still on RDS MySQL 5.7 crossed it on 1 March 2026 and is paying double right now. The 8.0 fleet has until 2028, and “we will upgrade next quarter” has a way of surviving two years.

Two things to check before you budget. Aurora deprecates on a separate schedule from RDS for MySQL, so do not assume the dates line up. And the figures above are us-east-1; other regions differ.

Turning the meter off does something you may not want

There is an EngineLifecycleSupport setting, and the CLI value is open-source-rds-extended-support-disabled. Setting it stops the charge. Read what AWS says happens next: “If you disable the enrollment status of a DB instance or DB cluster that is already past its standard support end date, the instance or cluster automatically upgrades to the next supported major version.”

Immediately. That is not a way to save money on a database you have not tested against 8.4. It is a way to trigger the migration you were deferring, unattended.

8.0 to 8.4 is a major version upgrade

MySQL changed its versioning scheme, so 8.4 sits where a 9.0 used to. RDS supports exactly two major upgrade paths today, 5.7 to 8.0 and 8.0 to 8.4, and MySQL 8.4 is supported under standard support until 31 July 2029.

The change that takes applications down is authentication. MySQL’s own manual is unambiguous: mysql_native_password is “deprecated as of MySQL 8.0.34, disabled by default in MySQL 8.4, and removed as of MySQL 9.0.0.” Any account still using it fails to connect after the upgrade, and the errors are ERROR 1045 (28000): Access denied and ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded, neither of which points at the real cause. You can re-enable the plugin with mysql_native_password=ON, and you should treat that as a short bridge, because 9.0 deletes it.

Audit the accounts before you upgrade, not after:

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

Three server defaults also flip in 8.4, and these change performance rather than break connections: innodb_change_buffering goes from all to none, innodb_adaptive_hash_index goes from ON to OFF, and innodb_flush_method moves to O_DIRECT where supported. A write-heavy workload that leaned on change buffering will feel the first one. Smaller items in the same release: WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() is gone and is now a syntax error, setting server variables to SQL NULL on the command line is rejected, and 8.4.4 and later want spatial indexes dropped before the upgrade and recreated after.

RDS runs pre-upgrade compatibility checks automatically when you start a major version upgrade, but they scan the schema. They do not read your application. Pair them with the account audit above and a grep through any raw SQL you own.

For the cutover itself, Blue/Green Deployments are the right tool for anything you cannot afford to break. Your 8.0 environment keeps serving while RDS builds and syncs an 8.4 one, the switchover is measured in seconds, and blue stays intact so a rollback is a flip rather than a restore. You pay for two environments briefly. Against a live per-vCPU-hour meter, that is a rounding error.

MariaDB: the deadline that is not an invoice

RDS gives MariaDB majors a grace period past community end of life, and it is longer than the community date, which is where people get confused. From AWS’s MariaDB version page:

Major version	Community end of life	RDS end of standard support
MariaDB 10.5	24 June 2025	31 August 2026
MariaDB 10.6	6 July 2026	31 December 2026
MariaDB 10.11	16 February 2028	February 2028
MariaDB 11.4	May 2029	May 2029
MariaDB 11.8	June 2028	June 2028
MariaDB 12.3	June 2029	June 2029

10.5 is nine days out as of this update. 10.6 has until the end of the year. Neither has a paid extension to fall into, so when the date arrives the automatic upgrade is the entire menu.

Picking the target is where MariaDB’s support policy gets counterintuitive. Community support for LTS releases used to run five years and now runs three, so the newest release is not the one with the longest runway. 11.8 came out in 2025 and expires June 2028. 11.4 came out a year earlier and runs to May 2029, eleven months longer. 12.3 arrived on RDS on 7 August 2026 and runs to June 2029, which beats 11.4 by about two weeks while being three major versions newer and two weeks old on the platform.

So: 11.4 if you want the long runway on a release that has been in production for two years, which is what I would pick. 12.3 if you want the newest and are comfortable being early. 10.11 only if you cannot tolerate the optimizer change below, and accept that you repeat this in early 2028.

The optimizer rewrite is the real work

Going from 10.6 to anything in the 11 series means inheriting MariaDB 11.0’s rewritten optimizer cost model. The cost of a storage engine operation is now pinned to roughly one millisecond, so LAST_QUERY_COST becomes proportional to actual time spent, and decisions that used to be rule-based became cost-based. ORDER BY is the clearest example: the old optimizer capped expected key lookups at ten percent of the table’s rows, which pushed it toward an index scan in cases where a full scan plus filesort would have been faster.

Better on average is not better for every query. Some plans improve, a few regress, and the regressions hide in your hottest queries. So capture a representative workload from 10.6, diff EXPLAIN output against a copy on the target version, run ANALYZE TABLE on the big tables right after upgrading because the new model leans harder on accurate statistics, and watch p95 and p99 rather than averages for a week.

For self-managed servers, upgrade one major version at a time, and do not skip mariadb-upgrade afterward. It fixes the system tables, and forgetting it is the other classic way this goes wrong at 2am.

Where to start today

Pull every RDS instance and note engine, major version, vCPU count, and Multi-AZ. On MySQL and Postgres, multiply vCPUs by $0.10 by 730 and double it for Multi-AZ; that number is your current monthly cost of not upgrading, and it is on this month’s bill whether or not anyone has looked. On MariaDB, find the date instead, because there is no number to pay.

Then run the prechecks on your most important database and see how much actually flags. Odds are the upgrade is smaller than what you are already paying to avoid it.