How PostgreSQL Manages Transaction Isolation
In PostgreSQL 8.0, transaction isolation controls what one transaction sees while other transactions change the database. PostgreSQL uses multiversion concurrency control (MVCC):…
When you choose a MySQL Server release, you decide how soon to adopt new features and how often to assess upgrades. Long-Term Support (LTS) releases keep a stable feature set and have a longer support window. Innovation releases deliver newer capabilities sooner and call for more frequent upgrades. Oracle describes both tracks as production-grade, with bug and security fixes.
Choose based on how often you can test and adopt releases. Choose LTS when you want to limit feature changes and plan maintenance over a longer period. Choose Innovation when you want newer features and can test and adopt releases regularly.
How the two release tracks differ
An LTS series keeps its feature set after its first release. Later releases provide fixes, so routine maintenance is less likely to change how MySQL behaves. Innovation releases can add features, change behavior, mark features as deprecated (no longer recommended), or remove features. Changes to SQL syntax, words that SQL reserves for its commands, or query execution can affect existing code and workload performance.
Test before upgrading either track. You need to test more frequently because Innovation releases arrive more often. The MySQL release documentation describes the tracks and their intended use.
| Track | Best fit | Upgrade expectation |
|---|---|---|
| LTS | A stable feature set and a longer support horizon | Apply fixes and plan upgrades around the LTS support lifecycle |
| Innovation | Earlier access to newer capabilities | Evaluate and adopt releases regularly |
Support depends on the track
Oracle’s Lifetime Support Policy gives an LTS series five years of Premier Support followed by three years of Extended Support. Premier Support includes maintenance releases and fixes. It also includes security alerts; Extended Support then provides three more years of support for specific releases. After those periods, Sustaining Support provides no new fixes for newly found issues. Check the support information for the specific release before planning its end-of-support date.
The current MySQL manual says an Innovation release is supported until the next Innovation release. That short window means you should plan to move forward regularly rather than expect to stay on one Innovation version for years. The release documentation provides the current track definitions; confirm the applicable support terms for your target version.
Read the version number in context
MySQL 9.7 is the last release series to use sequential version numbering. Subsequent versions use a calendar format: YY.M, where YY identifies the year and M the scheduled release month, without a leading zero. For example, 26.7 means July 2026, and 26.10 means October 2026. An LTS series keeps the calendar version assigned at its start.
Oracle’s published schedule describes quarterly releases, but future dates in the schedule are examples, not guarantees. For a date-specific reference, Oracle’s October 2026 announcement listed 26.10 Innovation, 9.7.4 LTS, and 8.4.13 LTS as available at that time. Check current release notes and downloads before choosing a version; that version snapshot can become outdated.
Plan the upgrade before choosing a track
If your organization cannot regularly test and adopt releases, choose LTS for its longer support window and more stable feature set. If you want newer capabilities and can keep pace with upgrades, Innovation offers a faster route to them.
Before changing a production server, read the release notes and verify the documented upgrade path for the exact source and destination versions. MySQL’s upgrade best practices recommend running the Upgrade Checker, a tool for checking upgrade readiness, testing code behavior in a separate environment, measuring performance on relevant workloads, practicing the upgrade, and validating a backup.
An upgrade and a downgrade use different methods. The manual says downgrading from an Innovation release requires a logical dump and load, which exports data and then imports it into the earlier version. Because the supported path for other transitions depends on the versions involved, verify it before changing a production server.
Also check the lifecycle for each MySQL product you use. MySQL Server and MySQL NDB Cluster have LTS and Innovation releases. MySQL Shell, Router, and Connectors follow a single current-release model. The Kubernetes Operator follows that model too, so these products’ shared version numbering does not give them the same support lifecycle.
What I'm buildingDelegate tasks. Get software.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com