Published: 2026-08-22

What's New in MySQL 26.7 — and Why There's No 9.8

MySQL 26.7.0 shipped on July 28, 2026 as an Innovation release, and it is the first MySQL release to use calendar versioning — YY.M.P, so 26.7 means "the July 2026 release." That is the whole answer to the question people are actually typing: there is no MySQL 9.8 and there never will be, because MySQL 9.7 was the final release line using the sequential versioning model. The current long-term-support line is still MySQL 9.7, released April 21, 2026. Below: what the new numbering actually means, what genuinely shipped in 26.7, and — first-hand — what changes when you point a desktop client at a server whose version string suddenly starts with 26. Everything here is as of August 2026 and sourced from Oracle's own release notes and manual.

The short version

The version number changed, not the product

The headline confusion of this release is the number. Per the MySQL 26.7 Reference Manual, Innovation releases now use a calendar-based Year.Month.Patch format: 26.7 represents the July 2026 release, and the manual's own forward example is that 27.7 would represent the July 2027 release. Three consequences are worth internalizing:

• There is no MySQL 9.8. 9.7 was the last line under sequential numbering, so anything promising "9.8 features" is either speculation or 26.7 described under a name it never got.
• The LTS lines keep their identities. 8.4 LTS and 9.7 LTS stay 8.4 and 9.7 for the rest of their support lifecycles; calendar versioning applies going forward, not retroactively.
• The track still decides your support window, not the number. An LTS series follows the Oracle Lifetime Support Policy — five years of Premier Support plus three years of Extended Support — and receives only necessary bug and security fixes. An Innovation release is supported until the next Innovation release, and is where behavior changes and deprecation removals land.

Upgrade paths are unchanged in spirit and worth quoting exactly, because a big-looking version jump tempts people to skip steps. The manual states that upgrading to the next LTS series is supported, such as 8.4.x LTS to 9.7.x LTS, while skipping an LTS series is not supported; and that you cannot upgrade directly between Innovation series of different major versions — you first upgrade to the nearest LTS series, then to the following Innovation series. So the road from 8.4 to 26.7 runs through 9.7.

What actually shipped in 26.7

The 26.7.0 release notes are dated 2026-07-28. The changes an operator or developer will actually notice:

Change Stream Applier: a second replication applier

The Change Stream Applier (CSA) is an opt-in, per-channel alternative to the multi-threaded applier, selected with new channel options:

-- MySQL 26.7
CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,              -- 1 = multi-threaded applier, 2 = CSA
  APPLIER_WORKER_COUNT = 8,         -- 1 to 1,024 workers per channel
  APPLIER_EVENT_MEMORY_LIMIT = 1073741824
  FOR CHANNEL 'ch1';

It is deliberately narrow: the release notes list no support for statement-based or mixed binary logging, file-position replication, sources with GTIDs disabled, delayed replication, or the legacy view-change log event. In other words it is for GTID-based, row-logged topologies — which is most modern ones, but check before you flip a production channel.

Thread Pool comes to Community Edition

The thread pool plugin, long an Enterprise-only feature, is now available in MySQL Community Edition 26.7.0, with thread_pool_max_unused_threads defaulting to 32 instead of 2. This is the second consecutive release to move an Enterprise capability into Community — 9.7 did the same for the hypergraph optimizer and several replication observability components.

Post-quantum TLS knobs

26.7 adds post-quantum cryptography settings, documented for TLS 1.3 with OpenSSL 3.5.0 or newer: force_pqc, tls_kex and use_pqc_sign, each with parallel variables for the admin interface, replication, Group Replication and X Protocol (admin_force_pqc, replication_tls_kex, mysqlx_use_pqc_sign, and so on), plus Tls_key_exchange_algorithm and Tls_sign_algorithm status variables to see what was negotiated. This is a server-side capability: whether a given client can complete a PQC handshake depends on that client's own TLS stack.

Smaller changes that bite

• Group Replication: group_replication_communication_stack and group_replication_ip_allowlist are deprecated, and the communication stack default changes from XCOM to MYSQL.
• Platforms: Enterprise Linux 7 and the generic glibc 2.17 build are no longer supported.
• InnoDB: undo truncate log files are no longer generated — the state lives in the undo tablespace header — while legacy truncate logs are still honored for backward compatibility.
• mysqldump: a new --extended-insert-multiline option puts each row of an extended INSERT on its own line, which is a real quality-of-life win for dumps that land in Git.
• Carried-over defaults: the what's-new page also documents the innodb_log_writer_threads default now depending on whether binary logging is enabled and how many logical CPUs the host has, and binlog_transaction_dependency_history_size raising its maximum from 1,000,000 to 10,000,000.

If you're still on 8.4: what 9.7 LTS brought

Since the supported route to 26.7 goes through 9.7, the LTS release is the one most 8.4 shops will actually adopt. From the 9.7.0 release notes (2026-04-21), the substantial parts:

• The hypergraph optimizer in Community Edition — enable it per session, globally, or per statement:

  SET optimizer_switch = 'hypergraph_optimizer=on';
  
  SELECT /*+ SET_VAR(optimizer_switch = 'hypergraph_optimizer=on') */ ...

• Replication observability in Community — the Replication Applier Metrics component, plus the Group Replication Flow Control Statistics, Resource Manager and Primary Election components, and the Telemetry component.
• DML on JSON duality views — INSERT, UPDATE and DELETE against duality views in Community Server, including auto-increment columns (with the ordering fix that later landed in 26.7).
• Authentication and privileges — PBKDF2 with SHA512 storage for caching_sha2_password, and the CURRENT_ROLE_IN() / CURRENT_USER_IN() gatekeeper functions that test the current role or user against a list.

Pointing a desktop client at a "26.7" server

Jam SQL Studio is a cross-platform desktop client (Mac, Windows, Linux) for SQL Server, PostgreSQL, MySQL, Oracle and SQLite. A version-numbering change is exactly the kind of event that quietly breaks GUI clients, because clients love to parse VERSION() and compare the major number. Here is what actually happens in Jam SQL Studio 1.4.21, verified in the code rather than assumed:

• One driver, one dialog. MySQL and MariaDB connections both go through the mysql2 driver (3.16.x as of 1.4.21), with pooled connections and optional TLS whose certificate validation stays on unless you explicitly trust the server certificate. There is no version to select when you create the connection.
• The version string is kept, not judged. On connect the app runs SELECT VERSION() once, stores the string verbatim, and picks the variant by testing whether it contains mariadb. A leading 26 is just text.
• Nothing MySQL-side is version-gated. No MySQL code path in the app compares a parsed server version against a threshold — the only engine that does version-conditional script generation is SQL Server. So calendar versioning cannot flip a feature off by accident, which is the failure mode to worry about in clients that gate on major < 8.
• Even the one version-flavored message is error-driven. Ask for an actual execution plan against a server too old for EXPLAIN ANALYZE and Jam reports "Actual execution plans require MySQL 8.0.18+ or a compatible MariaDB version" — but it gets there by running the statement and recognizing the server's parse error, not by reading the version number.
• The Performance Dashboard just says what the server says. The instance card labels the server MySQL <VERSION()>, so a 26.7 server reads MySQL 26.7.0, next to uptime, connected threads, buffer-pool memory from SHOW GLOBAL STATUS, and Top SQL from performance_schema.events_statements_summary_by_digest (skipped, not errored, when performance_schema is unavailable). See the Performance Dashboard guide.
• The Session Browser reads INFORMATION_SCHEMA.PROCESSLIST and enriches rows from performance_schema.threads where it can, and cancels with KILL QUERY over a separate admin connection.
• Scripts go to the server whole. Jam does not split your script on semicolons for normal execution — it uses the driver's multi-statement support, so semicolons inside BEGIN ... END are the server's problem, not yours. A DELIMITER line is rejected with an explanation, because it is a CLI-only directive.

The one thing 9.5+ genuinely changed for plan viewers

This one is worth flagging honestly, because it affects every GUI that renders MySQL plans. MySQL 9.5.0 (2025-10-21) changed the default of explain_json_format_version from 1 to 2. Version 2 is an access-path document whose nodes are operation objects nested under inputs arrays, matching the TREE output — not the older query_block tree:

// explain_json_format_version = 2 (default since 9.5)
{
  "query": "/* select#1 */ select ...",
  "operation": "Nested loop inner join",
  "access_type": "join",
  "inputs": [ { "operation": "Table scan on orders", "table_name": "orders" } ]
}

Jam SQL Studio's estimated-plan viewer models the version 1 shape as of 1.4.21, so on a 9.5, 9.7 or 26.7 server an estimated plan comes back as a single node instead of a tree. Two ways around it today: capture the actual plan — Jam runs bare EXPLAIN ANALYZE, whose default output format is TREE, and parses that natively — or set explain_json_format_version at the server level. A session-level SET from the editor is not reliable here, because each execution takes a connection from a pool and may not land on the one you configured.

What we have not wired up

To be explicit about the gaps rather than implying coverage: there is no UI for replication channels or the Change Stream Applier, the thread pool's performance_schema tables are not read anywhere, and we have not tested a connection against a server with force_pqc enabled — Jam connects with Node's TLS stack through mysql2, so PQC negotiation is a property of that stack, not something the app configures. JSON and enum Table Explorer filters build MySQL-specific SQL and are unaffected by any of this; see the JSON Columns guide for what those chips emit.

FAQ

Why did MySQL jump from 9.7 to 26.7?

Oracle moved MySQL to calendar versioning. Beginning with MySQL 26.7.0, Innovation releases use a Year.Month.Patch (YY.M.P) format, so 26.7 is the July 2026 release and, in the manual's own example, MySQL 27.7 represents the July 2027 release. MySQL 9.7 was the final release line using the sequential versioning model, which is why no MySQL 9.8 exists. The existing 8.4 and 9.7 LTS lines keep their names for the rest of their support lifecycles.

Is MySQL 26.7 an LTS release?

No. MySQL 26.7.0, released on July 28, 2026, is an Innovation release: it carries new features, behavior changes and deprecation removals, and it is supported only until the next Innovation release. The current LTS is MySQL 9.7, released on April 21, 2026, which follows the Oracle Lifetime Support Policy with five years of Premier Support and three years of Extended Support. Run Innovation if you want the newest features early; stay on 9.7 LTS if you want a line that receives only bug and security fixes.

Can I upgrade straight from MySQL 8.4 to MySQL 26.7?

Not in one step, going by the MySQL manual. Upgrading to the next LTS series is supported, such as 8.4.x LTS to 9.7.x LTS, while skipping an LTS series is not supported, and you cannot upgrade directly between Innovation series of different major versions. The documented path is to reach the nearest LTS first: 8.4 to 9.7 LTS, then 9.7 to 26.7.

Does Jam SQL Studio work with MySQL 26.7?

Yes. Jam SQL Studio connects to MySQL 26.7 through the mysql2 driver exactly as it connects to MySQL 8.4 or 9.7, using the same connection dialog it uses for MariaDB. After connecting it runs SELECT VERSION() once, keeps the string exactly as the server reports it, and decides MySQL versus MariaDB by looking for mariadb inside that string, so the Performance Dashboard instance card simply reads MySQL 26.7.0. No MySQL surface in the app is gated on a parsed version number, so the jump from 9.7 to 26.7 changes nothing about what lights up.

Why does my estimated execution plan look flat on MySQL 9.5 or newer?

Because the default JSON shape changed. MySQL 9.5.0 changed the default value of explain_json_format_version from 1 to 2, and version 2 is an access-path document built from operation and inputs keys instead of the older query_block tree. Jam SQL Studio's estimated-plan viewer models the version 1 shape as of version 1.4.21, so a version 2 payload renders as a single node rather than a tree. Capture the actual plan instead: Jam runs EXPLAIN ANALYZE, whose default output format is TREE, and parses that natively. Setting explain_json_format_version at the server level also works, while a session-level SET is unreliable because every execution takes a connection from a pool.