MySQL 8.0 exits standard support on Amazon RDS on July 31, 2026, and Extended Support fees begin the very next day. Here's how to decide between MySQL 8.4 LTS, 9.7 LTS, or Aurora before the meter starts running.
If your SaaS product, marketplace, or Laravel application still runs on MySQL 8.0, you have a hard deadline coming up fast. Amazon RDS and Aurora for MySQL 8.0 leave standard support on July 31, 2026, and Extended Support charges begin the following day. That's not a distant roadmap item anymore — it's less than two weeks away. This guide breaks down exactly what's changing, what it will cost you if you do nothing, and the three realistic migration paths available to teams running production workloads on MySQL today.
MySQL 8.0 has been in extended community support since mid-2025, but AWS ran its own clock on top of Oracle's. Standard support for RDS and Aurora MySQL 8.0 instances ends July 31, 2026. From August 1, 2026, every 8.0 instance you keep running is billed under RDS Extended Support — an additional per-vCPU-hour charge layered on top of your normal instance cost, with no reserved-instance discount applied to it.
This mirrors what happened with MySQL 5.7 and PostgreSQL 11 before it: AWS gives you roughly a two-year runway of paid extended support (charged at escalating rates by year) before the database is forcibly upgraded or the instance is stopped. It's a real deadline, not a soft nudge — and unlike a self-managed EC2 database, you can't simply ignore Oracle's EOL notice and keep patching yourself; RDS controls the engine version.
AWS has not published final region-by-region rates for MySQL 8.0 Extended Support as of this writing, but the pricing model is already established from the MySQL 5.7 and PostgreSQL 11 programs that came before it, and MySQL 8.0 follows the same structure: a per-vCPU-hour surcharge that increases the longer you stay on the unsupported version.
| Extended Support year | What changes | Who is affected |
|---|---|---|
| Year 1–2 (from Aug 1, 2026) | Base per-vCPU-hour surcharge on every running instance | Any RDS/Aurora instance still on engine version 8.0.x |
| Year 3 and beyond | Surcharge roughly doubles per vCPU-hour | Teams that delay migration past 2028 |
| Multi-AZ deployments | Surcharge applies per instance, including standbys | Production databases with a failover replica |
| Read replicas | Each replica billed separately under Extended Support | Read-heavy SaaS architectures |
The practical effect: a modest Multi-AZ production database with one read replica can see its effective database bill jump by a meaningful percentage the moment Extended Support kicks in, before you've gained a single new feature. For a bootstrapped SaaS or an agency running dozens of client databases, that adds up fast — and it's a recurring cost that only grows until you upgrade.
You have options beyond "pay the surcharge forever." Which one makes sense depends on how much operational risk you're willing to take on and how actively your database features are used.
| Path | Effort | Best for | Watch out for |
|---|---|---|---|
| Upgrade to MySQL 8.4 LTS | Low – in-place engine upgrade, minimal breaking changes | Most production apps that want the least disruptive path off 8.0 | 8.4 itself is on a shorter support clock than 9.7 LTS |
| Jump to MySQL 9.7 LTS | Medium – newer optimizer, some deprecated syntax removed | Teams that want the longest support runway and new Community Edition features like the Hypergraph optimizer and OpenTelemetry | Requires testing against the new query optimizer behavior before cutover |
| Move to Aurora MySQL | Medium–High – architectural change, not just a version bump | Teams already scaling past what RDS MySQL comfortably handles, or wanting Aurora's storage-layer failover | Different cost model; not a drop-in replacement for every workload |
For most Laravel and Node SaaS backends we work on, MySQL 8.4 LTS is the pragmatic default: it keeps you on the same broad engine family as 8.0, Laravel's Eloquent and migrations run against it without changes in the overwhelming majority of cases, and AWS supports it well into 2028. MySQL 9.7 LTS is worth the extra testing effort if you specifically want the new Community Edition features — replication observability, the Hypergraph optimizer, or a longer support window — or if you're standing up a new product from scratch.
If you do decide to leapfrog straight to 9.7, it's the first major LTS release since 8.4 and it moves several capabilities that used to be Enterprise-only into the free Community Edition:
“The teams that get burned aren't the ones who wait too long to decide — they're the ones who decide correctly but never schedule the work. A dated migration ticket beats a perfect plan sitting in a backlog.”
No. Upgrading your existing RDS for MySQL instance to 8.4 LTS or 9.7 LTS is enough to leave Extended Support behind — Aurora is a separate architectural decision worth making on its own merits, not something you're forced into by the EOL deadline.
8.4 LTS has a shorter runway than 9.7 LTS, which is positioned as the longer eight-year-supported line. If you're going to do the upgrade work anyway and don't need to minimize the size of the change, 9.7 LTS buys you more time before you're back here again.
You can, and for a database you're about to decommission anyway, that might be the rational choice. But for any database with more than a year of life left in it, the surcharge compounds — it roughly doubles in year three — and you're paying more for the same feature set you already have. Budgeting the migration is almost always cheaper over an 18-24 month horizon.
In most cases, no application changes are required for an 8.0 to 8.4 upgrade. Moving to 9.7 has a slightly higher chance of surfacing raw SQL that relies on removed syntax or deprecated SQL modes, which is why we recommend running your full test suite and a query audit against a staging copy before cutting over production.
Aurora MySQL 8.0 follows the same July 31, 2026 support boundary and the same Extended Support billing model as RDS for MySQL. The upgrade mechanics differ slightly — Aurora uses its own compatible engine versions — but the deadline and the financial incentive to move are identical.
Running production MySQL on AWS and need a migration plan before the August 1 deadline? Fepiq's team designs and executes zero-downtime database upgrades for Laravel and Node SaaS platforms on AWS.
Talk to our AWS database teamOccasional, no-fluff notes on shipping modern software — startups, automation, Laravel, Shopify and more. No spam, unsubscribe anytime.
Keep reading
Laravel Reverb or a Node.js microservice for real-time SaaS features? A 2026 decision framework covering scaling, cost, and the hybrid pattern most teams ship.
RDS PostgreSQL vs. Aurora PostgreSQL for SaaS in 2026: real cost numbers, when each wins, and a 5-question framework to pick the right one for your app.
Let's build something
Book a free discovery call. We'll listen, ask sharp questions, and send you a proposal within 3 business days.