MySQL 8.0 Lost New Fixes in April. Your Cloud Bill May Already Show It

The free fix window for MySQL 8.0 is closed

MySQL 8.0 has been the default for a lot of Oklahoma apps for years. Storefronts, logistics tools, clinic portals and SaaS products that started on 8.0 never had a hard reason to move. The engine was stable, drivers were everywhere and hiring managers could find people who knew it. That calm ended this spring when the support calendar finally caught up.

On April 21, 2026, Oracle announced that MySQL 8.0 is covered under Oracle Lifetime Sustaining Support. The notice tells users to upgrade to MySQL 8.4 LTS or 9.7 LTS. Sustaining Support is not a soft landing with the same patches. Oracle's Lifetime Support table shows that under Sustaining Support, software updates, security alerts and critical patch updates are limited to what already existed. New ones do not arrive.

That matters even if you never paid Oracle a support fee. The community release stream for 8.0 stopped with that change. If you run MySQL yourself on a server in Tulsa or on a VPS, you are on your own for new CVEs unless you move to a supported release or pay a vendor that backports fixes.

What Amazon RDS is charging you now

Most Oklahoma companies that use MySQL in the cloud run it on Amazon RDS. AWS publishes a clear calendar. Community end of life for MySQL 8.0 was April 30, 2026. RDS end of standard support was July 31, 2026. Extended Support year 1 pricing started August 1, 2026. Year 3 pricing starts August 1, 2028. Extended Support ends July 31, 2029.

AWS bills Extended Support per vCPU each hour, on top of the normal instance, storage and backup charges. The rate depends on the AWS Region and how many years have passed since standard support ended. Reserved Instance discounts do not apply to Extended Support. Multi AZ standbys and read replicas that still run 8.0 are charged too.

AWS also says you must be on an eligible Extended Support minor version to get those patches. As of late 2026 that line includes builds such as 8.0.46 RDS.20260908, which AWS released with critical security patches the community will never ship for 8.0. That keeps you safer than an abandoned community build, but you are paying for it every hour.

Azure and HeatWave are on different clocks

If your MySQL lives on Azure Database for MySQL, you have a little more time on standard support. Microsoft's version policy lists community retirement for MySQL 8.0 as April 30, 2026, Azure standard support ending January 31, 2027, Extended Support starting February 1, 2027 and Extended Support ending May 31, 2029. After standard support ends, Azure enrolls remaining 8.0 servers in Extended Support automatically and charges for it. Stopped servers are not charged. Running ones are.

Oracle HeatWave MySQL took a harder line. In an April 11, 2025 post, Oracle said HeatWave would not keep supporting 8.0 after April 2026 and that DB systems still on 8.0 would be upgraded to a supported 8.4 LTS version during a maintenance window. If you run HeatWave, confirm you are already on 8.4 and that your apps were tested for the move.

What breaks when you jump to 8.4

The supported upgrade path on RDS is MySQL 8.0 to MySQL 8.4. Azure offers an in place major version upgrade as well. 8.4 is an LTS release, which is the track most production teams want. Innovation releases exist, but they move faster than most Oklahoma IT teams want to follow for a system of record.

The move is not a rename. MySQL 8.4 turns off the old mysql_native_password plugin by default and leans on caching_sha2_password. Azure notes that existing accounts on the old plugin can keep working after the upgrade, but new accounts use the new one. Apps, ETL jobs and BI tools that still expect the old plugin will fail login until you update them.

Deprecated options and variables also go away. Oracle's HeatWave upgrade notes call out removals such as AUTO_INC with FLOAT, old SSL flags and obsolete variables. Test on a copy first. Take a backup you can restore. On RDS, a common pattern is to snapshot, restore to a new instance, upgrade the copy, run your app suite against it, then upgrade production once the copy looks clean. Blue and green deployments on RDS can shorten the cutover when your engine and Region support them.

Self hosted MySQL is the quiet risk. A single Ubuntu box in a closet or a cheap VPS can sit on 8.0.36 for years with automatic security updates turned off. Once Sustaining Support began, those hosts stopped receiving community builds with new CVEs addressed. A green monitoring graph is not the same as a supported engine. Either move that workload to a managed 8.4 service or stand up a new 8.4 host and cut over with a tested dump and restore. Check the engine version and the invoice, not just uptime.

Vendors that ship appliances or niche SaaS on MySQL 8.0 create a second list. Ask each one in writing which engine version they support in production today and when they will certify 8.4. If a vendor cannot move, isolate that system, put it behind tighter network rules and track it as tech debt with an owner and a date.

A practical upgrade checklist for Oklahoma teams

1. 1List every MySQL 8.0 instance you run, including RDS, Azure, HeatWave, self hosted servers, staging and forgotten vendor sandboxes.
2. 2For each cloud instance, open the bill and confirm whether Extended Support line items already appear.
3. 3Pick a target. For most teams that is MySQL 8.4 LTS. Confirm your ORM, connectors and reporting tools support it.
4. 4Clone production to a test instance, upgrade the clone and run your full smoke tests, including logins, migrations and overnight jobs.
5. 5Fix authentication first. Move remaining mysql_native_password users to caching_sha2_password before or right after the upgrade.
6. 6Schedule the production cutover in a quiet window, keep a tested restore path and watch error rates for the first day.
7. 7After the upgrade, confirm Extended Support charges stop on the next bill and that the console shows 8.4 everywhere you expect.
8. 8Write the new version and the next review date into your runbook so 8.4 does not become the next forgotten release.

What this means if you run a company in Oklahoma

A lot of Oklahoma companies have one or two MySQL databases that quietly power the whole business. Oilfield service firms, regional retailers, clinic groups and software shops around Oklahoma City and Tulsa often grew up on 8.0 and never scheduled the major version jump. The person who set the instance up may have left. The cloud console still says the instance is healthy, so nobody looks. Healthy is not the same as supported. Since August 1, 2026, every hour on RDS 8.0 has carried an extra charge, and Oracle will not ship you a new fix if a fresh CVE lands.

The cheap move is still available. Inventory the instances, test 8.4 on a copy and schedule the cutover before year 3 pricing on AWS and before Azure's February 2027 Extended Support start. Waiting only raises the bill and shortens the runway. A one week test plan costs less than months of Extended Support on a multi vCPU Multi AZ pair.

At Oklahoma Data Partners, we work only with data and only in Oklahoma. We help Oklahoma companies inventory aging MySQL estates, plan the move to 8.4 and watch the first weeks after cutover. If you want help getting off MySQL 8.0 before the next bill cycle, book a consultation.