According to the lifecycle data we checked, MySQL 8.0 reached the end of its listed extended support on 30 April 2026. If you still run it, record it as end of life, confirm any vendor or cloud provider arrangement in writing, and plan a move to a current long-term release.
What the lifecycle data shows
The lifecycle tracker we fetched lists MySQL 8.0 as an LTS release first published in April 2018, with premier support ending 30 April 2025 and extended support ending 30 April 2026. The latest 8.0 patch it lists is 8.0.46, from April 2026. The same data lists MySQL 8.4 as an LTS release with an end date of 30 April 2032, and 9.7 as an LTS release with an end date in April 2034.
That tracker is a secondary source. Oracle's own lifetime support documents are the authority, and we could not fetch them in a readable form for this review. Before you act on a date in an audit or contract, check it against Oracle's current documentation. Treat this post as a pointer to what to verify, not as the final word.
Why a database version is an inventory item
Databases are often missing from software inventories because they are infrastructure, not code. They still carry the same risk profile: a version, a support window, and exposure. A database server past its support date is also harder to patch around, because fixes ship in the server, not in a library you can swap.
Where the version shows up:
- Managed database services, in the engine version field.
- Docker Compose and Helm charts, in the image tag.
- Infrastructure as code, in an engine version variable.
- Application config, in a connection string or driver compatibility note.
Managed services may continue to patch an engine past the upstream date under their own terms. That is a provider promise with its own end date, so record the provider's date separately from the upstream date.
A migration outline
- Inventory every instance, including replicas, dev and test copies, and analytics clones.
- Pick the target. A current LTS release gives the longest window.
- Read the upgrade notes for removed features and changed defaults between your version and the target.
- Rehearse on a copy of production data. Compare query plans and error logs.
- Upgrade replicas first, then fail over, so you keep a rollback path.
- Keep a rollback plan with a tested backup and a stated time limit for the decision.
The general test method is in how to test a runtime upgrade.
What to write in the register while you migrate
| Field | Value |
|---|---|
| Component | MySQL 8.0, exact patch |
| Status | End of life per lifecycle data, verify with vendor |
| Compensating steps | Network restriction, least privilege accounts, backup tests |
| Owner and date | Named owner, target migration date |
Compensating steps reduce exposure. They do not make the component supported. See is paid extended support a compensating control for how to word that honestly.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning help you find the services and images that carry database engines, and compliance and evidence automation can keep the exception records in one place. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does a managed service make the version question go away?
No. The provider sets its own support dates. Record them and check them on a schedule.
Should I move to the newest innovation release?
For most production systems, an LTS release gives a longer window and fewer forced upgrades.
Sources
Last reviewed: 19 October 2026.
