MySQL® versioning policy

This document describes the lifecycle of major MySQL® versions in Yandex Managed Service for MySQL®. The policy is based on the official Oracle MySQL® support schedule and MySQL® Percona Extended Support schedule for a balance between cluster stability and maintaining a modern and secure infrastructure.

Terminology and lifecycle stages of MySQL® versionsTerminology and lifecycle stages of MySQL® versions

In Managed Service for MySQL®, each major MySQL® version has a lifecycle of 8–10 years comprising the following stages (statuses):

Version stage	Description and key actions	Approximate lifetime1
Current (Actual)	The latest LTS version with active support. Recommended for all new projects.	Years 1 through 5
Supported (Supported)	Previous LTS version with Percona Extended Support. Fully supported; allows creating new clusters.	Years 6 through 8
Deprecated (Deprecated)	Version approaching the end of Percona Extended Support. Creating new clusters is blocked. The existing clusters operate normally.	Year 9
Legacy extra paid (Legacy Extra Paid)2	Version that has no official support. Clusters operate normally, but are billed at an increased rate. Technical support is limited.	Year 10
End of life (EOL)2	Discontinued version. No technical support is provided. Clusters operate normally, but are billed at an increased rate.	Year 11 onward

¹ The periods are relative to the major version release date. The exact status change dates are officially announced by the service.
² Yandex will notify you in advance of the changes and the upcoming billing rate increase as per the Agreement.

Features for each versionFeatures for each version

Depending on MySQL® version status, the following operations are available for clusters:

Action	Current (Actual)	Supported (Supported)	Deprecated (Deprecated)	Legacy (Legacy)	EOL
Creating new clusters
Recovery from a backup
Use of existing clusters
Possibility of upgrading to a new major version	not applicable

Key principles of the MySQL® versioning policyKey principles of the MySQL® versioning policy

The MySQL® versioning policy is based on the following key principles:

• Support duration. Each LTS version remains Actual or Supported for eight years thanks to Percona Extended Support.
• Incremental deprecation. In its ninth year, the version gets the Deprecated status, making it impossible to create new clusters.
• Increased cost². In its tenth year, the version gets the Legacy Extra Paid status. Clusters are subject to extra pay; support is limited.
• End of life². After the EOL date (eleventh year and onwards), no support is provided any longer. Backup recovery is not possible. Clusters are operational but subject to extra pay.

² Yandex will notify you in advance of the changes and the upcoming billing rate increase as per the Agreement.

Update policyUpdate policy

• Minor updates (within the major version, e.g., 8.0.34 → 8.0.35) are installed automatically as part of maintenance performed during the cluster's stated maintenance window or at the customer's request. These updates contain security and bug fixes. A minor update requires a short, successive reboot of the cluster hosts.
• Major updates (changes of the major version, e.g., 8.0.x → 8.1.x) take place when the version goes from Deprecated to Legacy. The scheduled update appears in the Yandex Cloud interface ahead of time and can be canceled by contacting support. The EOL versions cannot be updated to a new major version. We highly recommend you to update before the EOL date.

NotificationsNotifications

Managed Service for MySQL® provides these early upcoming update notifications:

• When your MySQL® version turns Deprecated (limitations start to apply), the service will notify you 90 days in advance that you will no longer be able to create new clusters with your current MySQL® version, and suggest that your schedule an upgrade of your existing clusters.
• When your MySQL® version turns Legacy (increased rate starts to apply), the service will notify you 90 days in advance of the upcoming billing rate increase and issue the end of support warning.

Users will be receiving such notifications according to their notification settings.

Notifications about scheduled operationsNotifications about scheduled operations

The table below sets out the minimum user notification periods for different types of upcoming operations with Managed Service for MySQL® clusters.

Type of change	Minimum notification period3	Maximum migration period4
Internal version update that requires restarting hosts.	30 days	90 days
Internal version update that does not require restarting hosts.	3 days	7 days
Internal version update that requires switching the master or blocking write operations.	14 days	14 days
Security updates (maximum severity)	5 days	2 days
Security updates (high severity)	14 days	14 days
Security updates (medium severity)	21 days	30 days
Security updates (low severity)	28 days	120 days

³ Minimum number of days intervening between an upcoming operation and a notification about it from Yandex Cloud.
⁴ Period of time during which a user can manually reschedule the operation date via the management console.

Versioning scheduleVersioning schedule

The relevant status of major MySQL® versions by Percona is based on the official Oracle MySQL® support schedule and the Percona Extended Support schedule.

Version5	Current (Actual)	Supported (Supported)	Deprecated (Deprecated)	Legacy (Legacy)	EOL
MySQL® 8.4 LTS	2024–2029	2029–2032	2033	2034	2035
MySQL® 8.0 LTS	2018–2023	2023–2028	2029	2029	2030
MySQL® 5.7	—	—	end of 2026	2027	end of 2027

⁵ The exact timeline of transitions between MySQL® version statuses will be announced separately. The EOL dates match the end of Percona Extended Support dates.