MySQL 8.0 EOL on 31 July 2026: extended support costs and the 8.4 upgrade plan

Summary. Amazon RDS for MySQL 8.0 reaches end of standard support on 31 July 2026, and RDS Extended Support charges begin the day after. For a single db.r5.xlarge with 4 vCPUs in us-east-1, AWS puts that at $292 per month in years 1 and 2, and $584 per month in year 3. A Multi-AZ pair of the same instance class carries 8 vCPUs and costs $576 per month. Upstream, MySQL 8.0 moved into Oracle Sustaining Support on 21 April 2026. Azure Database for MySQL keeps standard support running until 31 December 2026 and starts billing Extended Support on 1 January 2027, ending 31 May 2029. Google Cloud SQL puts MySQL 8.0 extended support at 1 January 2027 with a deprecation date of 1 July 2029. The three clouds are on three different clocks, and only one of them bills you in 11 days.

That gap matters because the upgrade to MySQL 8.4 is not a version bump. MySQL 8.4.0 changed 17 InnoDB system variable defaults, stopped enabling mysql_native_password by default, and removed server options that a 2020-era my.cnf may still set. The work is real, and the deadline for the largest managed MySQL fleet is 31 July 2026.

The three deadlines that actually apply to you

Teams keep treating "MySQL 8.0 EOL" as one date. It is four, and they land in a different order than most runbooks assume.

Oracle moved the community MySQL 8.0 series into Sustaining Support first. The MySQL Product Support EOL Announcements page states that as of 21 April 2026, MySQL 8.0 is covered under Oracle Sustaining Support. Sustaining Support is the tier where you keep access to existing patches and documentation, not the tier where new security fixes arrive.

Your managed provider then applies its own clock on top:

• Amazon RDS for MySQL 8.0 reaches end of standard support on 31 July 2026, per the AWS Database Blog upgrade-strategies post published 14 May 2026.
• Azure Database for MySQL lists 8.0 with a community retirement date of 30 April 2026, Azure Standard Support ending 31 December 2026, Extended Support starting 1 January 2027 and ending 31 May 2029, in the Azure version support policy.
• Google Cloud SQL for MySQL 8.0 has an extended support start date of 1 January 2027 and a deprecation date of 1 July 2029, per the Cloud SQL database versions page.

If your fleet sits on RDS, you have days. If it sits on Azure or Cloud SQL, you have roughly five months of free runway before the meter starts. Plan the RDS instances first and do not let a single global "MySQL EOL" ticket flatten that difference.

There is a fourth date most teams miss entirely. AWS warns that individual minor versions inside MySQL 8.0 carry their own end of support dates that can land before the major version deadline. The blog gives 8.0.28, which reached end of standard support on 28 March 2024. Check the specific minor version you are running rather than assuming the major version date covers you.

Platform	MySQL 8.0 standard support ends	Paid extended support starts	Extended support ends
Community MySQL (Oracle)	21 April 2026 (moved to Sustaining Support)	Not applicable	Not applicable
Amazon RDS for MySQL	31 July 2026	1 August 2026, automatic	Up to 3 years after end of standard support
Azure Database for MySQL	31 December 2026	1 January 2027, automatic	31 May 2029
Google Cloud SQL for MySQL	Community EOL applies	1 January 2027	Deprecation 1 July 2029

What extended support actually costs

AWS bills RDS Extended Support per vCPU per hour, and the rate varies by Region. The published example table for us-east-1 in the AWS Database Blog is the number to plan against:

Deployment	Instance class	vCPU count	Year 1-2	Year 3
Single-AZ	db.r5.xlarge	4	$292/month	$584/month
Multi-AZ	db.r5.xlarge	8	$576/month	$1,152/month
Multi-AZ primary with Single-AZ read replica	db.r5.xlarge	12	$864/month	$1,728/month
Multi-AZ primary with Multi-AZ read replica	db.r5.xlarge	16	$1,168/month	$2,336/month

Two details in that table catch teams out. The billing is per vCPU, so a Multi-AZ deployment is charged twice because the standby carries the same instance class and vCPU count. And read replicas are billed independently, which is why the four-row table climbs to $1,168 per month for what most engineers would describe as "one database."

Run the arithmetic across a fleet and it stops being a rounding error. Ten Multi-AZ db.r5.xlarge pairs at $576 per month is $5,760 per month, or $69,120 across year one, to keep running a version you were already running. In year three the same fleet costs $1,152 per pair per month. The real cost is usually the migration you deferred, not the one you scheduled.

Azure and Google Cloud follow the same shape with different mechanics. Azure bills Extended Support per vCore per hour and applies it automatically to servers in a succeeded state, though the Azure documentation notes that servers in a stopped state are not charged. Google Cloud waived extended support charges for MySQL 5.6 and 5.7 from 1 February 2025 through 30 April 2025 and began charging on 1 May 2025, which is a useful precedent for how the 8.0 transition is likely to run.

The opt-out flag most teams miss

RDS Extended Support is automatic. It activates after the end of standard support date and continues until you upgrade. Most teams read that and assume the only exit is the upgrade itself.

There is a second lever. The RDS Extended Support charges documentation describes a lifecycle setting that prevents RDS from creating or restoring an instance past the end of standard support date at all. In the AWS CLI you pass open-source-rds-extended-support-disabled to the --engine-lifecycle-support option; in the RDS API it is the LifeCycleSupport parameter.

aws rds create-db-instance \
  --db-instance-identifier app-db-84 \
  --engine mysql \
  --engine-version 8.4.3 \
  --db-instance-class db.r5.xlarge \
  --engine-lifecycle-support open-source-rds-extended-support-disabled

Use this deliberately. It is a guardrail for new and restored instances, not a cost optimisation for the database currently serving production traffic. Setting it on a fleet you have not finished upgrading blocks restores you may need during the cutover.

The documentation is also explicit about how charges stop: upgrading to a version under standard support, or deleting the database, ends the additional charge. Charges restart if your target version later enters Extended Support itself, which is an argument for going to 8.4 LTS rather than an interim minor version.

What actually breaks between 8.0 and 8.4

The MySQL 8.4 reference manual documents 17 InnoDB system variables whose defaults changed from 8.0, plus three temptable settings in the same table. Several of them move performance-critical numbers by an order of magnitude, so a fleet that upgrades without reviewing its parameter group inherits a different I/O profile overnight.

InnoDB variable	MySQL 8.0 default	MySQL 8.4 default	Why it matters
innodb_io_capacity	200	10000	Background flushing becomes far more aggressive
innodb_log_buffer_size	16 MiB	64 MiB	Four times the memory reserved for the log buffer
innodb_adaptive_hash_index	ON	OFF	Removes an index layer some read-heavy workloads relied on
innodb_change_buffering	all	none	Secondary index writes stop being buffered
innodb_numa_interleave	OFF	ON	Changes memory allocation on multi-socket hosts
innodb_doublewrite_pages	4 (from innodb_write_io_threads)	128	Larger doublewrite batches
innodb_flush_method (Linux)	fsync	O_DIRECT if supported	Bypasses the OS page cache

The innodb_io_capacity jump from 200 to 10000 is the one to model first. That default was written for spinning disks; the new value assumes NVMe. If you are on gp3 volumes with a provisioned IOPS ceiling, aggressive background flushing can push you into throttling that never appeared under 8.0.

MySQL 8.4 also removed server options and variables outright, and attempting to set any of them raises an error rather than a warning. The removals include binlog_transaction_dependency_tracking (its WRITESET behaviour is now always used), group_replication_recovery_complete_at, avoid_temporal_upgrade, show_old_temporals, --no-dd-upgrade (use --upgrade=NONE), --old, --new and --language. A parameter group carried forward from 2020 has a real chance of containing at least one of these.

Then there is the terminology change. MySQL 8.4 completed the move to SOURCE and REPLICA keywords in place of the legacy MASTER and SLAVE forms, and the AWS post is direct about the consequence: review and update any scripts, automation, or documentation that references the old terminology. Monitoring checks that grep for SHOW SLAVE STATUS are the usual casualty.

The mysql_native_password trap, stated correctly

This one is widely reported wrong, so it is worth quoting the primary source. The MySQL 8.4 reference manual says that beginning with MySQL 8.4.0, the deprecated mysql_native_password authentication plugin is no longer enabled by default, and that you can enable it by starting the server with --mysql-native-password=ON or by including mysql_native_password=ON in the [mysqld] section of the configuration file.

Not enabled by default is different from removed. The plugin still exists in 8.4 and can be turned back on, which gives you a transitional path rather than a hard cutover.

Managed services diverge here, and the divergence is the part worth checking before you plan the migration:

• On Amazon RDS, caching_sha2_password is the default authentication plugin for RDS for MySQL 8.4, where 8.0 used mysql_native_password.
• On Azure Database for MySQL, the documentation states that mysql_native_password remains enabled across all versions in the service, and that existing user accounts using it continue to be supported after an 8.4 upgrade.

So the same upgrade carries different authentication risk depending on which cloud the instance sits in. Audit your accounts before the cutover:

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

Then confirm your drivers handle caching_sha2_password. Older PHP, Python and Node.js connector versions are the common failure point, and the failure mode is every application connection refusing to authenticate immediately after switchover.

Choosing an upgrade method

AWS documents three paths, and the trade-off is downtime against rollback quality.

Method	Downtime	Rollback	Best for
In-place upgrade	Minutes to hours, varying by deployment type and database size	Limited; automatic rollback may be possible, otherwise snapshot restore	Environments with an acceptable downtime window
RDS Blue/Green Deployment	Typically under 5 seconds at switchover	Immediate switchback to the blue environment with no data loss	Production upgrades needing minimal downtime and fast rollback
Snapshot restore	Hours, covering restore plus upgrade time	Original instance unchanged, but the endpoint changes	Dev and test validation before production cutover

Blue/green is the default recommendation for anything customer-facing. RDS builds the green environment from a snapshot of blue, keeps the two synchronised with binary log replication, and at switchover drops existing connections, performs a final sync and renames the green endpoints to match blue. Applications keep their connection strings. AWS announced in January 2026 that switchover times were reduced to under five seconds.

Two caveats the marketing does not lead with. Blue/green requires automated backups to be enabled. And the green environment loads its storage blocks from Amazon S3 on first access, so it experiences lazy loading effects: the first queries against green are slower than steady state, which will skew any benchmark you run in the first minutes after creation.

In-place upgrades cannot be cancelled once started. For Multi-AZ instance deployments, RDS upgrades primary and standby simultaneously, so you take downtime on both. And a completed major version upgrade cannot be rolled back automatically, which is why the pre-upgrade snapshot matters even when automated backups are on.

A two-week plan you can still run

The RDS deadline is 31 July 2026. Here is the sequence that fits.

Start with the precheck, because it is free and it runs without downtime. RDS runs mandatory prechecks automatically before the instance is stopped, and if they find incompatibilities it cancels the upgrade and leaves your 8.0 instance untouched. Findings land in PrePatchCompatibility.log:

aws rds download-db-log-file-portion \
  --db-instance-identifier your-db-instance-id \
  --log-file-name PrePatchCompatibility.log \
  --output text

A non-zero errorCount means the upgrade did not proceed. Resolve everything flagged before you book a production window. You can also run the community MySQL Shell upgrade checker utility against a copy for a second opinion.

Confirm your valid upgrade targets rather than guessing at a version number:

aws rds describe-db-engine-versions \
  --engine mysql \
  --engine-version 8.0.42 \
  --query 'DBEngineVersions[0].{CurrentVersion:EngineVersion,AvailableUpgrades:ValidUpgradeTarget[*].EngineVersion}' \
  --output json

Then work through the rest in order. Build a new parameter group on the mysql8.4 family, because 8.4 requires it, and compare every value you have customised against the new defaults rather than copying the old group forward. Upgrade read replicas before the primary, cross-Region replicas first, then in-Region; failing to do so blocks the upgrade. Take an explicit manual snapshot immediately before the window even though RDS takes its own, because it gives you a known-good restore point and speeds up the automatic pre-upgrade snapshot.

After the switchover, warm the database. The engine restart evicts the entire InnoDB buffer pool, and AWS is specific about how to repopulate it: run your most commonly executed queries, and avoid broad SELECT * queries that flood the buffer pool with data your workload does not actually touch. Then watch the slow query log and CloudWatch metrics for the first few hours rather than declaring success at switchover.

The AWS authors put the parameter-group risk plainly: "Deprecated parameters are a common source of post-upgrade surprises that are easier to catch before the upgrade window than after it." That is Shagun Arora, Senior Database Specialist Solutions Architect at Amazon Web Services, writing with Kiranmayee Mulupuru, Database Specialist Technical Account Manager at AWS, and Poulami Maity, Database Specialist Solutions Architect at AWS.

India-specific considerations

For teams running production MySQL out of ap-south-1 (Mumbai), three things change the calculation.

Extended Support pricing varies by Region, so the us-east-1 example table is a planning anchor, not your invoice. Model your own fleet in the AWS Pricing Calculator before you take a number to finance. The shape of the cost holds even where the rate differs: per vCPU, doubled for Multi-AZ, and again for every read replica.

Budget cycles matter more than the engineering. An Indian company on an April-to-March financial year is being asked to absorb an unplanned dollar-denominated operating cost from August, four months into the year, with no line item for it. Getting the upgrade done before 31 July avoids a conversation about a variable USD charge that grows with fleet size and doubles in year three.

Data protection obligations run alongside this. Under the Digital Personal Data Protection Act 2023, a database holding personal data that stops receiving security patches is difficult to defend as a reasonable security safeguard. Running past end of standard support without either the paid Extended Support tier or an upgrade leaves you without a supported patch path. Our DPDP engineering playbook for Indian startups covers how that maps onto the rest of the stack.

The pattern here is not unique to MySQL. We wrote up the same shape of decision for ingress-nginx reaching end of life and the Gateway API migration, and for teams weighing the Postgres 18 upgrade with async I/O and UUIDv7. Deadline-driven infrastructure work is cheapest when it is scheduled and most expensive when it is discovered. If cloud spend is the trigger for this project rather than the deadline, the FinOps moves Indian teams use to cut AWS, Azure and GCP spend are a useful companion.

FAQ

When exactly does Amazon RDS for MySQL 8.0 reach end of standard support?

Amazon RDS for MySQL 8.0 reaches end of standard support on 31 July 2026, according to the AWS Database Blog post published on 14 May 2026. RDS Extended Support charges begin the day after that date. Individual minor versions within 8.0 carry their own earlier end of support dates, so check yours.

How much does RDS Extended Support cost for MySQL 8.0?

AWS bills Extended Support per vCPU per hour, with rates varying by Region. The published us-east-1 example puts a Single-AZ db.r5.xlarge with 4 vCPUs at $292 per month in years 1 and 2 and $584 per month in year 3. A Multi-AZ pair with 8 vCPUs costs $576 per month.

Can I avoid RDS Extended Support charges without upgrading immediately?

Charges stop when you upgrade to a version under standard support or delete the database. Separately, AWS provides a lifecycle setting, open-source-rds-extended-support-disabled on the --engine-lifecycle-support option, that prevents RDS from creating or restoring instances past the end of standard support date entirely.

Is mysql_native_password removed in MySQL 8.4?

No. The MySQL 8.4 reference manual states the plugin is no longer enabled by default from 8.4.0, and can be re-enabled with --mysql-native-password=ON or mysql_native_password=ON in the mysqld configuration section. On Amazon RDS, 8.4 defaults to caching_sha2_password. Azure keeps the native plugin enabled across versions.

Which upgrade method gives the least downtime?

RDS Blue/Green Deployments. AWS reports switchover times under five seconds after a January 2026 improvement, and the blue environment stays live throughout so switchback is immediate with no data loss. It requires automated backups enabled, and the green environment shows lazy loading effects while storage blocks load from S3.

What InnoDB defaults change between MySQL 8.0 and 8.4?

Seventeen InnoDB system variable defaults changed in 8.4.0. The largest jumps are innodb_io_capacity from 200 to 10000 and innodb_log_buffer_size from 16 MiB to 64 MiB. Others include adaptive hash index moving from ON to OFF and change buffering moving from all to none.

Do Azure and Google Cloud have the same MySQL 8.0 deadline as AWS?

No. Azure Database for MySQL runs Standard Support to 31 December 2026, starts Extended Support billing on 1 January 2027 and ends it on 31 May 2029. Google Cloud SQL sets extended support start at 1 January 2027 with deprecation on 1 July 2029. Only the RDS deadline falls in July 2026.

What should I check before running the upgrade in production?

Run the RDS prechecks and clear every finding in PrePatchCompatibility.log, since a non-zero errorCount blocks the upgrade. Build a new mysql8.4 parameter group rather than reusing the old one, audit accounts still on mysql_native_password, upgrade read replicas first, and take a manual snapshot immediately beforehand.

How eCorpIT can help

eCorpIT runs database upgrades and cloud migrations for teams that cannot take an unplanned outage or an unplanned bill. Our senior engineering teams handle the parts that go wrong quietly: parameter group review against the new 8.4 defaults, driver compatibility testing for caching_sha2_password, blue/green rehearsal with a measured rollback, and a Region-specific Extended Support cost model so finance sees the number before August rather than after. If you have MySQL 8.0 in production and a deadline in days, talk to us about a migration plan.

References

1. MySQL Product Support EOL Announcements - Oracle, MySQL. Confirms MySQL 8.0 moved to Oracle Sustaining Support as of 21 April 2026.
2. Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4 - AWS Database Blog, 14 May 2026. End of standard support date, Extended Support cost table, upgrade methods.
3. Amazon RDS Extended Support charges - Amazon RDS User Guide. Billing start, how charges stop, and the engine lifecycle opt-out.
4. Amazon RDS Extended Support overview - Amazon RDS User Guide.
5. Azure Database for MySQL version support policy - Microsoft Learn, updated 14 May 2026. Azure standard and extended support dates and plugin behaviour.
6. Database versions and version policies, Cloud SQL for MySQL - Google Cloud Documentation, updated 13 July 2026. Extended support start and deprecation dates.
7. What Is New in MySQL 8.4 since MySQL 8.0 - MySQL 8.4 Reference Manual. InnoDB default changes, authentication plugin behaviour, removed options.
8. Changes in MySQL 8.4 - MySQL 8.4 Reference Manual.
9. MySQL 8.4 Keywords and Reserved Words - MySQL 8.4 Reference Manual.
10. Amazon RDS Blue/Green Deployments reduces downtime - AWS What's New, January 2026.
11. Best practices for upgrading Amazon RDS for MySQL 8.0 to 8.4 with prechecks, Blue/Green, and rollback - AWS Database Blog.
12. Extended support in Cloud SQL - Google Cloud Documentation.
13. AWS Pricing Calculator - Amazon Web Services.

Last updated: 20 July 2026.