Amazon RDS for MySQL 8.0 reached the end of standard support on July 31, 2026. Databases still on 8.0 did not stop working: AWS automatically enrolled them in RDS Extended Support, which keeps security fixes coming for an additional charge per vCPU, per hour, on top of the normal instance cost. For most organizations, that charge is the clearest reason to plan the move to MySQL 8.4 now rather than later.
Check where you stand
- In the AWS console, open RDS, then Databases, and look at the Engine version column.
- Note every database on 8.0.x, including staging and test databases, which are also charged.
- In Cost Explorer, filter by the RDS service and look for Extended Support line items.
Aurora MySQL has its own version timeline, separate from RDS for MySQL; check it separately if you use Aurora.
What Extended Support means
- Security fixes continue for a limited period, for a fee that rises in later years.
- The fee scales with the database's size (vCPUs), so a large database on an old version costs much more to keep than a small one.
- It buys time; it is not a destination. Every database still needs to reach a supported version.
Check the RDS pricing page for current rates, and your bill for what you are actually paying.
What changes in MySQL 8.4
MySQL 8.4 is a long-term support release, and the move from 8.0 is smaller than the 5.7 to 8.0 jump. Things to test:
- Authentication: the older
mysql_native_passwordmethod is disabled by default in 8.4. Applications and users still relying on it need updating, or the method enabled deliberately during the transition. - Removed and changed settings: custom parameter groups must be recreated for the 8.4 family; review any settings carried over from 8.0.
- Replication terminology and options changed; scripts or tools that manage replication may need updates.
- Application compatibility: run your CMS or application's test suite against an 8.4 copy.
Upgrading safely
- Snapshot first, and confirm the snapshot restores.
- Upgrade a copy: restore a snapshot as a test database, upgrade it to 8.4, and point a staging site at it.
- Test sign-in, forms, search, reports, and integrations.
- Use a blue/green deployment for production where possible: RDS keeps the current database serving while an upgraded copy is prepared, then switches over with a short interruption.
- Keep the rollback ready until the application has run cleanly on 8.4.
A realistic timeline
| Step | Typical effort |
|---|---|
| Inventory and cost check | An hour |
| Upgrade a test copy and fix compatibility issues | Days, depending on the application |
| Application testing by your team | A few days |
| Production switch with blue/green | A planned window; minutes of interruption |
Start with test and staging databases: they are charged too, and they are where compatibility problems should show up first.
Common questions
Can we opt out of Extended Support? Not for existing databases once enrolled; the way out is upgrading to a supported version.
Will WordPress and Drupal run on MySQL 8.4? Current versions do; check your plugins, modules, and custom code in staging.
What about MySQL 5.7 databases? They have been in Extended Support longer and cost more; upgrade them first, through 8.0 to 8.4.
How much downtime should we expect? With a blue/green switchover, usually a brief interruption of about a minute while connections move. An in-place upgrade without blue/green takes longer, so it is best kept for small, non-critical databases.
Do we need to change our application's connection settings? Usually not: blue/green keeps the same endpoint. Check any connection that uses the old authentication method described above.
What if a problem shows up after the switch? Keep the old database available until the application has run cleanly through a normal business cycle, including month-end or scheduled reports if you have them.
Does upgrading change our backups? Snapshots taken before the upgrade stay on 8.0; keep the pre-upgrade snapshot until you are confident.
How eWay handles database upgrades
On environments eWay manages, database engine versions are moved in step with what the application supports, validated in a test environment first, with a pre-change backup point and a tested rollback. Under the shared responsibility model, eWay handles the engine upgrade, backups, and platform settings; your team owns database users, schema, and data, and confirms the application works on the new version; see shared responsibility on AWS.
What to include in a support ticket
- The database names and current versions
- Who will test the application, and any dates to avoid
eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: reading your AWS bill and database performance.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article