필사 모드: The Version After MySQL 9.7 Is 26.7 — How MySQL and MariaDB Tidied Up Their Release Models in Spring 2026

• Introduction — The Version After 9.7 Is Not 9.8
• An Innovation Release Ends the Moment the Next Innovation Release Ships
• MySQL 9.7 LTS — The First Harbor in Two Years
• What 9.7 Handed Down to the Community Edition
• Calendar Versioning — What YY.M Tells You
• MariaDB Did the Same Thing Five Weeks Later
• Where They Diverge — 8 Years of Support vs. 3
• Where They Diverge, Part Two — A Default Change the Release Notes Didn't Pin Down
• So What Should You Actually Do
• Closing
• References

Introduction — The Version After 9.7 Is Not 9.8

As of July 2026, the version number of MySQL's next innovation release is 26.7. That is not a typo.

On June 16, 2026, Oracle announced in A More Predictable MySQL Release Model that it is switching MySQL version numbers to calendar versioning. And the first entry of the MySQL 26.7.0 release notes confirms it.

MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series. Version values use Year.Month.Patch (YY.M.P) format. MySQL 26.7.0 is the first such calendar-version release.

The jump from 9.7 to 26.7 is, by itself, just notation. What's interesting is that this change is the conclusion of how the MySQL release model has actually run over the past two years, and what's more interesting is that MariaDB did nearly the same thing five weeks apart. This post works through both threads, checked against the release notes and support-policy documents themselves.

This post focuses on the release model and operational judgment calls. MariaDB's internals (storage engines, Galera, partitioning) are covered separately in MariaDB Architecture — From Storage Engines to Galera.

An Innovation Release Ends the Moment the Next Innovation Release Ships

First, a refresher on the Innovation/LTS model introduced in 2023. The key sentence is in MySQL 9.7 Reference Manual, section 1.3.

Innovation releases are supported until the next Innovation release.

One sentence, but operationally it's a fairly heavy condition. While you're running an innovation release, your support window is "until the next release ships," and there's no option but to upgrade to keep getting support after that — no option to just wait for a patch release.

The same document draws the LTS distinction this way.

These releases only contain necessary fixes to reduce the risks associated with changes in the database software's behavior. There are no removals within an LTS release.

And it says this about innovation releases, in contrast:

Apart from new features in innovation releases, behavior changes are also expected as code is refactored, deprecated functionality is removed, and when MySQL is modified to behave more in line with SQL Standards.

That "deprecated functionality is removed" isn't an abstract warning — 9.0 proved it directly. The MySQL 9.0.0 release notes record that the mysql_native_password authentication plugin was removed from the server. Something deprecated in 8.0 disappeared in the very next major — and any organization still holding onto old clients or connectors gets caught here.

So how long did each innovation release actually live? Below are the GA dates as printed in the Oracle release-note titles, carried over verbatim. The end-of-support date is, per the rule above, simply the GA date on the next row.

Seven times over two years — once a quarter. If you ran the 9.x line in production, staying supported meant doing a major upgrade every quarter.

As a side note, 9.0.0 comes with an extra footnote. The top of the release notes reads: "This release is no longer available for download. It was removed due to a critical issue that could stop the server from restarting following the creation of a very large number of tables (8001 or more)." Creating 8,001 or more tables could keep the server from restarting, so 9.0.0 was pulled and replaced by 9.0.1 — a case study in what kind of track the innovation releases are.

Which is exactly why the manual is candid about who it recommends the innovation track to — "developers and DBAs working in fast-paced development environments with high levels of automated tests and modern continuous integration techniques for faster upgrade cycles." In other words, organizations that can test and push through a major upgrade every quarter. Most organizations aren't that, and admitting you aren't is the first step to using this model correctly.

MySQL 9.7 LTS — The First Harbor in Two Years

The GA date on the MySQL 9.7.0 release notes is 2026-04-21. The previous LTS, 8.4.0, had a GA of 2024-04-30 per its release notes — so the gap between LTS releases is nine days short of two years.

The support windows are laid out in Oracle's Lifetime Support Policy document (Effective Date: May 1, 2026). It only goes down to month granularity, but it is the primary source.

The row that stands out here is 8.0. Premier ended in April 2025, and Extended ended in April 2026. Oracle's EOL notice page states it plainly: "As of April 21, 2026, MySQL 8.0 is covered under Oracle Sustaining Support" — the very day 9.7.0 LTS went GA. Sustaining Support, in Oracle's terminology, runs indefinitely but comes with no new fixes, no security alerts, and no new certifications. In effect, 8.0 — which has carried a large share of the internet since 2018 — is now effectively frozen.

What LTS gives you is equally explicit in the manual.

Functionality remains the same and data format does not change in an LTS series, therefore in-place upgrades and downgrades are possible within the LTS series.

That you can even downgrade within the same LTS line is the real reason people pick LTS in practice. An upgrade with a rollback path and one without are different kinds of work.

What 9.7 Handed Down to the Community Edition

The change actually worth noting in 9.7 LTS isn't so much the features themselves as where the edition boundary moved. The components the release notes list as formerly Enterprise-only and now available in the community edition are:

• Replication Applier Metrics Component
• Group Replication Flow Control Statistics Component
• Group Replication Resource Manager Component
• Group Replication Primary Election Component
• Telemetry Component

On top of that, the release notes add two more items — "The Hypergraph Optimizer is now available in MySQL Community Edition," and DML (insert/update/delete) support for JSON Duality Views landed in the community server.

Telemetry reaching the community edition matters a fair amount for operations teams — it means you can export logs, metrics, and traces via OpenTelemetry/OTLP, whereas previously running MySQL through the same observability pipeline as the rest of your stack on the community edition meant bolting on a separate exporter. The Hypergraph optimizer is also worth attention, since it's used for exploring complex join plans.

That said, the direction isn't entirely one-way. In the same release, Dynamic Data Masking landed newly on the Enterprise side. Oracle's 9.7 announcement post describes it as "server-side protection of sensitive data without requiring application changes" — a feature that attaches masking policies to base-table columns and returns either the original or masked value depending on the executing user or role. What went to the community and what went into Enterprise sit side by side in the same release.

There's context behind this. On February 17, 2026, Percona publicly proposed discussing MySQL governance in An Open Letter to Oracle. That post claims Oracle moved MySQL to OCI and cut staff in fall 2025, putting the scale at "roughly 50%" — that's Percona's claim, not a figure Oracle has confirmed, so there's no basis for taking it as fact as-is. Still, the items the same post said it hoped to see in 9.7 — vector functions in the community edition, a Hypergraph optimizer enabled by default, JSON Duality with full DML, PGO builds — are indeed confirmed in the 9.7 release notes. And it's only fair to note that the same post still lists "vector indexes" among what it still wants. Going by Percona's own phrase, "verification through action, not words," may be the standard to judge by — and the fact that the edition boundary actually moved is at least grounds that it wasn't only words.

Calendar Versioning — What YY.M Tells You

Back to 26.7. Oracle's June 16 announcement defines the format as follows.

• YY — the last two digits of the year
• M — the release month, with no leading zero (January is 1, April is 4, July is 7, October is 10)

The upcoming cadence examples the post gives are:

26.7   – July 2026 Innovation release
26.10  – October 2026 Innovation release
27.1   – January 2027 Innovation release
27.4   – April 2027 Innovation release
27.7   – July 2027 Innovation release
27.10  – October 2027 Innovation release
28.1   – January 2028 Innovation release
28.4   – April 2028 LTS release
28.7   – July 2028 Innovation release

How LTS is handled is the core of this design. A line designated LTS keeps that YY.M prefix for its entire lifetime — 28.4.0 → 28.4.X → 28.4.Y → 28.4.Z — so even seeing 28.4.10 in 2030, you'd know from the number alone that it's "the LTS line that started in April 2028." In Oracle's words: "This ensures an LTS line retains the identity of exactly when it started."

The real information practitioners should take away here isn't the notation itself but the example list. The next LTS listed is 28.4 — April 2028. Since 9.7 LTS is April 2026, that's a signal the LTS interval is again about two years. That said, the list is titled "Upcoming Cadence Examples," not a roadmap commitment, so don't take April 2028 as contractual. Still, from a planning standpoint the message is clear — if you dock at 9.7 LTS now, the next harbor is roughly two years out.

The announcement post also introduces new maintenance terminology. CPU (Critical Patch Update) is Oracle's regular quarterly security-patch cycle, and CSPU (Critical Security Patch Update) is a targeted security update shipped between quarters when needed. The post pins CSPU down as "strictly as-needed," explicitly stating it does not create a monthly obligation. It also notes that the quarterly package doesn't carry only security fixes — LTS packages carry security and bug fixes, while innovation-release packages add new features on top.

What happens to existing lines? Per the announcement and the table, 8.4 and 9.7 LTS are unaffected and keep their existing numbering scheme. Calendar versioning applies to releases after 9.7.

And there's one thing to pin down precisely about 26.7.0 itself. The release-notes title reads "Changes in MySQL 26.7.0 (Early Access Release)." It's Early Access, not GA. The first output to carry the new version number is not a production release, so seeing the number 26.7 is not a reason to plan an upgrade around it.

There is one compatibility courtesy, though. 26.7.0 adds MYSQL_PREVIOUS_LTS_VERSION ("9.7.0") and MYSQL_PREVIOUS_LTS_VERSION_ID (90700) to mysql_version.h (WL #17310). Jumping the version number from 9 to 26 could break build scripts and connectors that simply compared numbers, so the header now spells out the previous LTS version explicitly so lineage can still be traced. Put the other way around: if you have code that parses the version string, you now have a reason to go check it.

MariaDB Did the Same Thing Five Weeks Later

What's interesting here is that MariaDB runs an effectively identical structure, independently.

The MariaDB Foundation's 12.3 LTS announcement is dated May 29, 2026 — five weeks after MySQL 9.7 LTS. The announcement states, "The first GA of the 12.3 series is 12.3.2" — in MariaDB, .2 is the first GA (.0 is preview, .1 is RC).

The 12.0, 12.1, and 12.2 before it were rolling releases. The wording in the MariaDB release model document is nearly a carbon copy of Oracle's rule.

There are no patch version releases of an innovation release after GA (except for emergency releases), instead users are supposed to upgrade to the next minor innovation release. In other words, innovation releases are rolling releases, one upgrades 11.3.2→11.4.2→11.5.2→11.6.2→11.7.2

The same document states "Approximately every fourth innovation release is a long-term support (LTS) release," and the MariaDB Foundation's maintenance policy states "A new long-term release (LTS) of MariaDB Server is announced yearly." Rolling every quarter, LTS once a year.

Put together, the two camps' structures overlap like this:

MySQL    : Innovation every quarter  -> LTS roughly every 2 years  (support ends when the next Innovation ships)
MariaDB  : Rolling every quarter     -> LTS every year             (support ends when the next Rolling ships)

Two competing implementations arriving at the same conclusion suggests this isn't marketing — it's closer to engineering convergence, as if "this is the only way to maintain a major open-source database." Separate the fast track from the slow track, and don't promise long-term support on the fast track.

Where They Diverge — 8 Years of Support vs. 3

With the structures aligned, the real difference now stands out. How many years you can ride an LTS release is completely different between them.

The MySQL manual states:

An LTS series follows the Oracle Lifetime Support Policy, which includes 5 years of premier support and 3 years of extended support.

5 + 3 = 8 years. The 9.7 row in the Lifetime Support table above (Premier April 2031, Extended April 2034) is exactly that arithmetic.

The MariaDB Foundation's maintenance policy is different.

MariaDB Community LTS binaries are released for 3 years after the GA date on mariadb.org/download

You need the footnotes to get the full picture. Footnote 2 states, "For releases up to MariaDB 11.4, the binaries are released for 5 years after the GA date." In other words, community LTS binary support used to be 5 years through 11.4 and has since shrunk to 3 years. Footnote 1 adds a cushion — "Critical and security fixes will be provided in source code releases for 2 additional years beyond Community LTS binary release period." Binaries get 3 years, but critical and security fixes keep coming as source releases for 2 more years after that. If you can build from source yourself, the effective window is 5 years; if you depend on distro packages, it's 3. That distinction matters a lot in practice.

Paying changes things. The same policy document states that Enterprise binaries get "an extended release option maintained and supported for 5 and 8 years, respectively, after the GA date."

In one line: for an organization running only the community edition, MySQL LTS gives you 8 years and MariaDB LTS gives you 3. That's the most practical difference hiding behind the phrase "both are open-source MySQL-compatible databases."

To be fair, MariaDB's LTS ships every year, so the harbor itself comes around more often. It's closer to a choice between crossing a big gap once every 8 years, versus a small one every 3. Which is cheaper depends on your organization's upgrade muscle.

One caution: in the MariaDB Foundation's maintenance-policy table, 12.3's GA date and EOL are still blank as TBC as of this writing. So I haven't written an exact EOL date for 12.3 here. The "3 years" is a policy statement; once the date is finalized, that table is the primary source.

Where They Diverge, Part Two — A Default Change the Release Notes Didn't Pin Down

The 12.3 LTS announcement flags exactly one item as "Important."

In MariaDB 12.3, innodb_snapshot_isolation defaults to ON

And adds: "There probably is no better moment than when we release a new LTS."

First, what this feature actually does. Per the MariaDB InnoDB system variables documentation, innodb_snapshot_isolation is a switch inside InnoDB that detects write/write conflicts. When it's on, trying to lock a record that doesn't exist in the current read view raises ER_CHECKREAD (error 1020), and that error is handled the same way as a deadlock, rolling back the transaction. It affects the default isolation level, REPEATABLE READ. In the documentation's own words, the design rejects UPDATE/DELETE on rows modified by a concurrent transaction after the snapshot, to prevent anomalies like lost updates.

Correctness-wise, this is the right direction. The problem is that the application doesn't know about it. An UPDATE that quietly succeeded yesterday now rolls back with error 1020, and without retry logic it surfaces as an outright failure. It's exactly the kind of change you don't want to meet in an LTS upgrade.

Here, though, the documentation and the announcement disagree. The same system-variables document states the default as:

Default Value: ON (>= MariaDB 11.6.2), OFF (<= MariaDB 11.6.1)

That says it's been ON since 11.6.2, not 12.3. Checking the source settles which one is right. Looking at the default-value argument for this variable, branch by branch, in storage/innobase/handler/ha_innodb.cc:

innodb_snapshot_isolation default by MariaDB/server branch
  11.4  -> FALSE
  11.5  -> FALSE
  11.6  -> TRUE
  11.7  -> TRUE
  11.8  -> TRUE
  12.2  -> TRUE
  12.3  -> TRUE
  main  -> TRUE

The documentation is right. The default flipped at 11.6, not at 12.3.

So for someone who only tracks LTS releases, the real picture looks like this:

11.4 LTS (OFF)  ->  11.8 LTS (ON)  ->  12.3 LTS (ON)
                     ^^^ already flipped here

In other words, this change shipped already in effect as of 11.8 LTS. And the 11.8 LTS announcement never once mentions snapshot isolation. To sum up:

• Organizations that went 11.4 → 11.8 hit this behavior change but were never told about it in the announcement.
• Organizations jumping 11.4 → 12.3 are only now being told — but the framing "this changes in 12.3" isn't accurate.
• For organizations going 11.8 → 12.3, this item is actually not a change at all. It was already ON.

This isn't meant to fault the announcement — flagging it prominently, even late, was the right call, and it's exactly the warning someone coming from 11.4 LTS needs. The point is elsewhere — a release note's "this changes now" is written against the path its author assumed, not necessarily your upgrade path. Skip two LTS steps at once, and every default that quietly flipped in the rolling releases in between arrives all at once. Skipping rolling releases is a reasonable operational choice, but it doesn't mean you can skip the changelog for the gap you skipped too.

In practice, diffing SHOW GLOBAL VARIABLES between both versions before an LTS upgrade is more reliable than reading the announcement post. For what it's worth, this feature is still being refined — MariaDB's Jira still has lock-wait/deadlock issues related to innodb_snapshot_isolation being on (MDEV-40182, MDEV-40092, and others) tagged with 10.11 / 11.4 / 11.8 / 12.3 as fix versions in 2026.

So What Should You Actually Do

Boiled down, the calls are simple.

If you're on MySQL 8.0 — now is the moment. Extended Support ended in April 2026, and you're now on Sustaining Support — meaning no new security fixes. Your destination is 8.4 LTS (Extended through April 2032) or 9.7 LTS (through April 2034). Because mysql_native_password was removed starting in 9.0, an 8.0 → 9.7 jump needs a client/connector authentication check done first. If that work isn't something you can take on right now, 8.4 LTS is an honest waypoint.

If you're running a 9.x innovation release — move to 9.7 and stop there. Support has ended for everything from 9.0 through 9.6. 9.7 is the LTS in the same lineage, and within an LTS line both in-place upgrades and downgrades are possible.

Don't put 26.7 in production. It's Early Access. And what the calendar-versioning announcement implies for the next LTS is April 2028 (28.4). Docking at 9.7 now is the right call.

Do you even need to ride the innovation track? Mostly, no. It's only worth it if you have the CI and staffing to test and push through a major upgrade every quarter, and a specific new feature is a genuine business need. Otherwise, staying on LTS is the normal path this model intends. That's what the Oracle manual says, too.

If you're on MariaDB — 12.3 LTS is your current harbor. But don't misjudge the support window. Community binaries get 3 years (down from 5 years through 11.4), and after that, only 2 more years of critical/security fixes come as source releases. If you depend on distro packages, plan around an effective 3 years to be safe. And if you're coming up from 11.4 or earlier, make absolutely sure in staging that innodb_snapshot_isolation turning ON doesn't break you — if your application has no retry path for error 1020, this is where it will blow up.

If you're torn between MySQL and MariaDB — this post doesn't answer that. But support duration (community 8 years vs. 3) and upgrade cadence (2 years vs. 1) rarely show up in feature-comparison tables, yet they land squarely in operational cost — worth computing before you get to benchmarks.

Closing

The jump from 9.7 to 26.7 is a notation change, but the story behind it isn't about notation.

From 2024 through 2026, MySQL shipped an innovation release every quarter, and each one's support ended the moment the next one shipped. Those two years' worth of output landed as 9.7 LTS on April 21, 2026, and the same month, 8.0 dropped into Sustaining Support, closing out an era. MariaDB did the exact same thing five weeks later with 12.3 LTS. Two competing implementations arriving at the same release structure isn't a coincidence — it's convergence.

And underneath, the real differences are still split apart. Eight years versus three years of community-edition support; Oracle moving the edition boundary toward the community while MariaDB shrank community-binary support from 5 years to 3; and default-value changes that arrive quietly whenever you skip between LTS releases.

Calendar versioning lets you tell "when this release started" from the number alone. That's a genuinely useful improvement. But what the number doesn't tell you — what got removed in between, and which defaults flipped — still requires opening the release notes, and sometimes the source, to find out. Just as confirming one variable, innodb_snapshot_isolation, in this post meant looking through seven branches.

References

• MySQL 9.7 Reference Manual 1.3 — MySQL Releases: Innovation and LTS
• Changes in MySQL 9.7.0 (2026-04-21) — release notes
• Changes in MySQL 26.7.0 (Early Access Release) — first calendar-versioning release
• Changes in MySQL 9.0.0 (2024-07-01) — mysql_native_password removed, 9.0.0 recall notice
• A More Predictable MySQL Release Model: Calendar Versions, LTS, and Innovation (Oracle, 2026-06-16)
• MySQL 9.7.0 LTS Is Now Available (Oracle, 2026-04-21)
• Oracle Lifetime Support Policy — Technology Products (Effective May 1, 2026, PDF)
• MySQL Product Support EOL Announcements
• MariaDB Server 12.3 LTS Released (MariaDB Foundation, 2026-05-29)
• MariaDB Foundation — Maintenance policy
• MariaDB Release Model document
• MariaDB InnoDB System Variables — innodb_snapshot_isolation
• MariaDB/server — storage/innobase/handler/ha_innodb.cc (default-value verification)
• An Open Letter to Oracle: Let's Talk About MySQL's Future (Percona, 2026-02-17)
• MariaDB Architecture — From Storage Engines to Galera (related post)