MySQL 26.7 and Calendar Versioning: Which MySQL Should You Run Now?

The MySQL downloads page now lists 26.10.0 above 9.7.4 LTS, and there is no 9.8. Point a 26.7 server at a data directory created by a 9.6 Innovation release and the upgrade is rejected, because only a 9.7.x LTS server can move into the first calendar-versioned line. MySQL 9.7 LTS went GA on 21 April 2026 and reached 9.7.4 on 20 October 2026. Every release after it uses calendar versions: 26.7.0 shipped on 28 July 2026 and 26.10.0 on 20 October 2026, both on the Innovation track. MySQL 8.0, meanwhile, reached end of life in April 2026 with 8.0.46. This guide explains the LTS and Innovation tracks, how to read the new version numbers, what 26.x adds over 9.7, the upgrade and downgrade rules, what Amazon RDS and Aurora offer today, and which version to run in each situation.

Scope and review date: November 2026. This post covers Oracle MySQL Community Server 8.0, 8.4, 9.x, and 26.x, self-managed and on Amazon RDS and Aurora. Percona Server and MariaDB version their releases differently and are not covered. Versions, dates, and commands were checked against Oracle's and AWS's documentation on 9 November 2026. The commands were not run in a lab, so try them on a non-production server first.

How does the MySQL release model work in 2026?

MySQL has two tracks. The MySQL 9.7 manual's release model page calls both production-grade. They differ in how much changes between releases and how long each one is supported.

An LTS series (8.4, 9.7) adds and removes features only in its first release, such as 9.7.0. Later patches carry only necessary fixes and keep the data format, so in-place upgrades and downgrades work inside the series. Support is 5 years Premier plus 3 years Extended.

An Innovation release (9.0 to 9.6, 26.7, 26.10) can add features, change defaults, and remove functionality, which the manual warns "might require application changes". Each one is supported only until the next ships.

You choose the track in the package repository, not on the server. The MySQL Yum repository guide enables the 9.7 LTS subrepository by default and leaves 8.4 (mysql84-community) and Innovation disabled. It advises enabling only one release series at a time.

# Which MySQL track will the next "dnf update" follow?
dnf repolist all | grep mysql

Interpretation: exactly one server subrepository should show as enabled. If mysql-innovation-community is enabled on a production host, the next routine update can move it to a new Innovation release with new behavior.

How do you read MySQL 26.7 and 26.10 version numbers?

The 26.7.0 release notes say MySQL "now uses calendar-based versioning for releases after the 9.7 LTS series", in Year.Month.Patch (YY.M.P) form. 26 is 2026, 7 is the scheduled release month without a leading zero, and the patch number starts at 0. So 26.10.0 is the October 2026 release, and a fix to it would be 26.10.1.

Two rules make the numbers less obvious than they look:

• The number does not tell you the track. The 26.10 manual states that "a calendar version does not determine whether a release is an Innovation or LTS release". The downloads page labels 9.7.4 and 8.4.13 as LTS and lists 26.10.0 and 26.7.0 without the label.
• An LTS series keeps its YY.M for life. When a calendar-versioned LTS ships, its patches change only the last number, the way 9.7.0 became 9.7.4.

A fourth component arrived in October 2026. The 9.7.4 release notes, the 8.4.13 notes, and the 26.10.0 notes all add a MAJOR.MINOR.PATCH.UPDATE release identity, with an empty update shown as zero. VERSION() and @@version keep the three-part form, so existing scripts keep working.

A query that sorts servers into tracks has to use @@version and treat every calendar version as "check the track":

SELECT @@hostname AS host, @@version AS version,
  CASE
    WHEN @@version LIKE '8.0.%' THEN '8.0: end of life since April 2026'
    WHEN @@version LIKE '8.4.%' THEN '8.4 LTS'
    WHEN @@version LIKE '9.7.%' THEN '9.7 LTS'
    WHEN @@version REGEXP '^9\\.[0-6]\\.' THEN '9.x Innovation: no longer supported'
    WHEN CAST(SUBSTRING_INDEX(@@version, '.', 1) AS UNSIGNED) >= 26
      THEN 'Calendar version: confirm the track in the release notes'
    ELSE 'Older series: check the upgrade path'
  END AS track;

Interpretation: run it on every server. A row in the first or fourth category is on a series that no longer receives fixes.

Which MySQL versions exist now, and which are still supported?

The release train runs from 8.0 through two LTS series to the first calendar-versioned releases.

Status as of November 2026, from the release note indexes and Oracle's Lifetime Support Policy for technology products (effective 2 October 2026):

26.7.1 (18 August 2026) is a security update for the MySQL Server Docker image only. The 9.7 release notes index shows the quarterly rhythm: 9.1.0 to 9.6.0 shipped every January, April, July, and October from October 2024, and 26.7 and 26.10 keep those months.

The next LTS has not shipped. Percona's write-up of the new model says it is expected in April 2028 as 28.4.0, and the 26.10 manual's upgrade examples use a 28.4.0 LTS. Treat that date as a plan until Oracle releases it.

Is MySQL 8.0 end of life?

Yes. The MySQL 8.0 release notes say: "As of April 2026, with version 8.0.46, MySQL 8.0 reaches End of Life (EoL)." Oracle's policy table shows Premier Support for 8.0 ending in April 2025 and Extended Support in April 2026. No 8.0.47 is coming from Oracle, so the fixes in the July and October 2026 releases have no 8.0 build.

On Amazon RDS for MySQL, 8.0 left standard support on 31 July 2026 and now runs only under paid RDS Extended Support, which ends on 31 July 2029, with AWS-built minors such as 8.0.46-RDS.20260908. Aurora MySQL version 3, the 8.0-compatible line, stays in standard support until 30 April 2028.

# RDS: which instances still run 8.0 (and pay for Extended Support)?
aws rds describe-db-instances \
  --query "DBInstances[?Engine=='mysql'].[DBInstanceIdentifier,EngineVersion]" \
  --output table

Interpretation: any 8.0.x or 8.0.46-RDS.* version is billed for Extended Support. The same applies to 5.7.44-RDS.*.

What is in MySQL 26.x that 9.7 LTS does not have?

9.7 gets fixes, not features. Everything below is only in the Innovation line, per the 26.7.0 and 26.10.0 release notes.

Added in 26.7.0

• Change Stream Applier. An opt-in replica applier per channel, chosen with APPLIER_VERSION = 2. It supports only row-based binary logs, GTID channels with GTID_MODE=ON, and no delayed replication.
• Post-quantum key exchange in TLS 1.3. It needs OpenSSL 3.5.0 or later and adds variables such as force_pqc, tls_kex, and use_pqc_sign.
• Thread Pool plugin in Community Edition. It was Enterprise-only before 26.7.0. The default thread_pool_max_unused_threads also changes from 2 to 32.
• innodb_autoinc_preallocate. It reserves extra AUTO_INCREMENT values, so values can be skipped after a crash.

-- Based on the 26.7.0 release notes example: move one channel to the new applier
STOP REPLICA SQL_THREAD FOR CHANNEL 'channel_name';
CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,
  APPLIER_WORKER_COUNT = 8,
  APPLIER_EVENT_MEMORY_LIMIT = 1073741824
  FOR CHANNEL 'channel_name';
START REPLICA SQL_THREAD FOR CHANNEL 'channel_name';

Interpretation: the release notes say the SQL thread must be stopped before an existing channel changes applier. APPLIER_VERSION = 1 remains the multi-threaded applier and the default for new channels. Test the new applier on a replica you can rebuild.

Added in 26.10.0

• MySQL REST Service as a server component (component_mysql_rest_service), serving HTTPS on port 33443 by default without a separate MySQL Router.
• Health Monitor and the authentication_webauthn plugin in Community Edition.
• JSON duality view annotations (CHECK, NO CHECK, UPDATE, NO UPDATE). Replicas must be upgraded before a source replicates DDL that uses them.

Changes that can break an application or a host

• 26.7.0 makes CUBE, EXTERNAL, QUALIFY, and TABLESAMPLE reserved words.
• 26.7.0 changes the group_replication_communication_stack default from XCOM to MYSQL and deprecates both it and group_replication_ip_allowlist.
• 26.7.0 drops Enterprise Linux 7, and 26.10.0 drops OpenSSL older than 1.1.1. Check /etc/os-release and openssl version on every candidate host.
• 26.10.0 rejects abbreviated optimizer_switch values such as o and of with ER_WRONG_VALUE_FOR_VAR.

-- On 9.7: columns and tables whose names become reserved words in 26.7
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM information_schema.COLUMNS
WHERE UPPER(COLUMN_NAME) IN ('CUBE', 'EXTERNAL', 'QUALIFY', 'TABLESAMPLE')
   OR UPPER(TABLE_NAME)  IN ('CUBE', 'EXTERNAL', 'QUALIFY', 'TABLESAMPLE');

Interpretation: every row is an identifier that must be quoted with backticks on 26.7 and later. Search application SQL too: aliases and CTE names are not in information_schema.

What upgrade and downgrade paths does calendar versioning allow?

From 26.7.0, a server that starts on a data directory from another version checks compatibility lineages, not just version numbers. The 26.10 upgrade paths page sets these rules:

• A sequentially numbered release can enter the first calendar-versioned lineage only from 9.7.x LTS.
• An Innovation release can upgrade only to a later release in the same lineage, including the LTS that closes it.
• An LTS release can upgrade into the next lineage, but cannot skip one.

The manual's own examples:

Downgrades are stricter. Inside an LTS series, such as 9.7.4 back to 9.7.3, an in-place downgrade is supported. The downgrade paths table allows only a logical dump and load or replication from one LTS back to the previous one, or from a later Innovation release to an earlier one, and only for rollback, meaning no new server functionality has touched the data. Clone has its own rules in the 26.7.0 notes: it works within a version and across patches, and from one LTS to the next. It refuses an older or non-consecutive LTS recipient, or a non-LTS pair whose major or minor versions differ.

# Check a server against the exact target before any hop
mysqlsh -- util checkForServerUpgrade root@db-01:3306 \
  --target-version=9.7.4 --output-format=JSON

Interpretation: run the newest MySQL Shell, since Shell follows the newest server version and supports all current servers. Errors must be fixed before the upgrade, and warnings need a decision. For the full 8.4 to 9.7 procedure, see Upgrading MySQL 8.4 LTS to 9.7 LTS.

Can you run MySQL 9.7 or 26.x on Amazon RDS or Aurora?

Not in production yet. The RDS for MySQL versions page lists 8.4 (newest minor 8.4.11) and 8.0 under Extended Support as the production majors. MySQL 9.7 and 26.7 are available only in the Database Preview environment, which deletes instances after 60 days and offers no AWS Support. RDS supports major upgrades from 5.7 to 8.0 and from 8.0 to 8.4.

AWS publishes its own timelines: RDS adds a new Oracle LTS major within 6 months of the community's .1 release, and the Aurora MySQL release calendar commits to 12 months. Community 9.7.1 shipped on 16 June 2026, so those clocks have started. Aurora's newest line is Aurora MySQL version 8.4, at 8.4.10 since 26 October 2026. Innovation releases go only to the RDS Preview environment.

# What can this account actually create today?
aws rds describe-db-engine-versions --engine mysql \
  --query "DBEngineVersions[].EngineVersion" --output text
aws rds describe-db-engine-versions --engine aurora-mysql \
  --query "DBEngineVersions[].EngineVersion" --output text

Interpretation: if no 9.7 version appears, your managed target is 8.4 for now. You can still test 9.7 compatibility on a self-managed server.

Which MySQL version should you run?

This table is our reading of the support dates and upgrade rules above, as of November 2026:

Innovation in production makes sense only when you can test and ship a database upgrade every quarter.

Frequently asked questions

Key takeaways

Plan your MySQL version strategy with JusDB

JusDB's MySQL upgrade team can review your fleet's versions and support dates, run the MySQL Shell compatibility checks against your target, and plan the hops from 8.0 or 8.4 to the LTS series that fits your platform, including RDS Extended Support exits.

Bring your server inventory, hosting platform, replication topology, and maintenance windows. Your team approves every production change.

Related reading

• MySQL 8.0 is EOL: upgrade checklist for 8.4 LTS
• Upgrading MySQL 8.4 LTS to 9.7 LTS: path, checks, and rollback
• MySQL 8.4 LTS production readiness checklist
• MySQL documentation: MySQL Releases, Innovation and LTS