MySQL and MariaDB Release History: 3.23 to LTS, the Fork and Security

MySQL began at the Swedish company MySQL AB in the 1990s, was bought by Sun Microsystems (announced January 2008) and passed to Oracle when Oracle completed its purchase of Sun on 27 January 2010. Today it ships on two tracks: Long Term Support (LTS) lines, currently 8.4 and 9.7, and Innovation releases, which switched to calendar version numbers with MySQL 26.7.0 in July 2026. MariaDB is the community fork started in 2009 by MySQL's original developers, now with its own yearly long term releases and quarterly rolling releases.

The security story across both projects comes down to three threads: the slow retirement of the SHA-1 based mysql_native_password scheme, stronger default authentication (caching_sha2_password in MySQL; unix_socket, ed25519 and PARSEC in MariaDB), and encrypted connections moving from optional to expected. Every date and version below was checked against dev.mysql.com, Oracle's own lifetime support document and press releases, mariadb.org or MariaDB's documentation.

Key takeaways

• Two projects, one ancestor. MariaDB versions up to 5.5 worked as drop in replacements for the equivalent MySQL version. From 10.0 the projects diverged, and MariaDB is not a drop in replacement for MySQL 8.0 or later.
• MySQL has two tracks. LTS lines (8.4, 9.7) receive only necessary fixes and follow Oracle's Lifetime Support Policy: 5 years of premier and 3 years of extended support. Innovation releases add, change and remove features, and each is supported only until the next Innovation release.
• MySQL now uses calendar versions. 9.7 was the last sequentially numbered line; 26.7.0 (28 July 2026) and 26.10.0 (20 October 2026) use a YY.M.P format, and the version number alone does not tell you whether a release is LTS.
• MySQL 8.0 gets no new fixes. Oracle's support document lists premier support ending April 2025 and extended support April 2026; since 21 April 2026 8.0 is in Sustaining Support, which excludes new fixes and Critical Patch Updates.
• mysql_native_password is gone from the MySQL server. Deprecated in 8.0, disabled by default in 8.4.0 (30 April 2024) and removed in 9.0.0 (1 July 2024). MariaDB still supports it.
• MariaDB's support windows changed. Community long term binaries now get 3 years after GA (5 years for lines up to 11.4), plus 2 years of source only critical and security fixes. Rolling releases arrive quarterly.
• TLS is expected but not always enforced. MySQL clients try TLS first, but require_secure_transport still defaults to OFF in MySQL 8.4. MariaDB 11.4 encrypts non local connections by default with an in memory certificate.
• MySQL security fixes ship in Oracle's quarterly Critical Patch Updates on the third Tuesday of January, April, July and October. The next is 19 January 2027.

How did MySQL begin?

MySQL AB and the mSQL roots

The MySQL reference manual tells the origin story in its "History of MySQL" section. The founders set out to connect their tables to the mSQL database system using their own fast low level ISAM routines. After testing they concluded that mSQL was neither fast enough nor flexible enough, so they wrote a new SQL interface with almost the same API as mSQL. The point of that choice was practical: third party code written for mSQL could be ported to MySQL easily. The manual also records that MySQL is named after co founder Monty Widenius's daughter, My, and that the dolphin in the logo is called Sakila, a name picked in a user contest.

The company behind the code was MySQL AB. By the time of the Sun deal, Sun's press release described MySQL as headquartered in Cupertino, California and Uppsala, Sweden, with 400 employees in 25 countries. The early release lines (3.23, 4.0 and 4.1) predate the support records Oracle publishes today, and Oracle's lifetime support table for MySQL begins with 5.0.

Sun Microsystems, 2008

On 16 January 2008 Sun Microsystems announced a definitive agreement to acquire MySQL AB for about $1 billion in total: roughly $800 million in cash for all MySQL stock and the assumption of about $200 million in options. Sun's release called MySQL "an open source icon" and said the deal was expected to close in late Q3 or early Q4 of Sun's fiscal 2008, subject to regulatory approval. For roughly two years MySQL was a Sun product, and the MySQL 5.1 GA release, which Oracle's support document dates to December 2008, shipped in that period.

Oracle, 2010

On 20 April 2009 Oracle and Sun announced a definitive agreement under which Oracle would acquire Sun for $9.50 per share in cash, a transaction Oracle valued at about $7.4 billion, or $5.6 billion net of Sun's cash and debt. Oracle announced on 27 January 2010 that it had completed the acquisition. MySQL has been an Oracle product since then. Oracle's lifetime support document for technology products now lists MySQL Database alongside its other products, with the same premier, extended and sustaining support tiers, and MySQL 5.5 (GA December 2010) was the first major MySQL line to reach GA under Oracle.

Why MariaDB started in 2009

MariaDB's own "About MariaDB Server" page describes the server as "made by the original developers of MySQL and guaranteed to stay open source", and says it was originally designed as an enhanced, drop in replacement for MySQL. The foundation's team biographies place the start of the project in 2009, and one of them traces a developer's path from MySQL AB, to Sun, to Monty Program AB and later MariaDB Corporation. The motive recorded on mariadb.org is continuity: a community developed, GPL licensed MySQL compatible server that would stay open source whatever happened to the commercial owner of MySQL.

MariaDB's release history on mariadb.org starts with the 5.1 series. Its first stable release, 5.1.42, is dated 1 February 2010, which the foundation's maintenance table also uses as the 5.1 GA date.

The MariaDB Foundation and MariaDB plc

Two organisations carry the MariaDB name, and they do different jobs.

• The MariaDB Foundation is the non profit that runs mariadb.org, publishes the maintenance policy and the release list, and governs contributions to MariaDB Server. Its first public progress report, posted by Monty Widenius in October 2013, covers its work from December 2012. Its board includes founding directors (Widenius among them), directors representing organisational members, including MariaDB plc, and individual directors.
• MariaDB plc (earlier MariaDB Corporation) is the commercial company. It sells MariaDB Enterprise Server with longer enterprise and extended support windows, and its documentation site hosts most of the technical reference pages cited in this post.

When this post says "MariaDB documentation" it means mariadb.com/docs; "mariadb.org" means the foundation. The distinction matters for support dates, because the foundation publishes community dates and the company publishes enterprise dates, and the two are now different.

Timeline: MySQL and MariaDB releases and milestones

MySQL dates from 5.0 onward come from Oracle's lifetime support document (month and year) and from the MySQL release notes (exact days). MariaDB dates come from the maintenance table and the all releases page on mariadb.org.

How do MySQL release lines and version numbers work?

Before 2023: one series at a time

For most of its life MySQL followed a simple pattern. A major series (5.5, 5.6, 5.7, 8.0) went through development milestone releases and release candidates, reached GA and then received point releases for years. The 8.0 series stretched that pattern. Oracle added features and changed behaviour inside 8.0 point releases: the "What is new in MySQL 8.0" page is full of entries tagged "as of MySQL 8.0.x", and the 8.0.4 release made caching_sha2_password the default authentication plugin while 8.0.28 dropped TLSv1 and TLSv1.1. Teams that treated 8.0.x as a patch stream sometimes found that a routine update changed a default.

The LTS and Innovation model

Oracle introduced the Innovation and LTS model in 2023, starting with MySQL 8.1.0 on 18 July 2023. The 8.4 reference manual describes it in section 1.3, "MySQL Releases: Innovation and LTS":

• LTS releases are for environments that need a stable feature set and a longer support period. They contain only necessary fixes, to reduce the risk of behaviour changes. There are no removals within an LTS release; features can be added or removed only in the first release of an LTS line, such as 8.4.0. Support follows Oracle's Lifetime Support Policy: 5 years of premier support and 3 years of extended support.
• Innovation releases are for developers and DBAs who want the latest features and have the automated testing to upgrade often. Behaviour changes are expected as code is refactored, deprecated functionality is removed and MySQL moves closer to the SQL standard. The manual warns that these changes can affect SQL syntax, reserved words, query execution and performance. An Innovation release is supported only until the next Innovation release.

The manual is explicit that all LTS and Innovation releases include bug and security fixes and are considered production grade quality. The real difference is how much change you accept per upgrade, not whether one track is tested less.

The release notes give the sequence. 8.1.0 (18 July 2023), 8.2.0 (25 October 2023) and 8.3.0 (16 January 2024) were Innovation releases. 8.4.0 (30 April 2024) began the first LTS line. 9.0.0 (1 July 2024) through 9.6.0 (20 January 2026) were Innovation releases, roughly one per quarter. 9.7.0 (21 April 2026) began the second LTS line, and its patch releases have continued through 9.7.4 on 20 October 2026.

Upgrade paths between tracks

The 8.4 manual sets out the upgrade rules:

• Within an LTS series the data format does not change, so in place upgrades and downgrades both work, for example from 8.4.0 to any later 8.4.x. The clone plugin is another option.
• Upgrading to the next LTS series is supported, such as 8.4.x to 9.7.x. Skipping an LTS series is not.
• An Innovation installation upgrades to a later Innovation release, but you cannot jump directly between Innovation series of different major versions. The manual's example: to move from 8.3.0 to 9.0.0, upgrade to the nearest LTS (8.4.0) first.
• The official MySQL repository treats the first LTS release as both LTS and Innovation, so an Innovation track repository moves you through the LTS release automatically.
• Downgrading an Innovation release requires a logical dump and load.

The repository choice is how you pick a track on Linux. With Yum, the manual names mysql-innovation-community for the Innovation track and mysql-8.4-lts-community for the 8.4 LTS track.

Calendar versioning from 26.7

The 26.10 reference manual adds a section on version numbers. MySQL 9.7 was the final release line using sequential numbers. Later Innovation and LTS releases use calendar versioning in YY.M.P format: a two digit year, the release month, and a patch number starting at 0. MySQL 26.7.0, the July 2026 release, is the first calendar versioned release; 26.7.1 (18 August 2026) is a patch release in the same line; 26.10.0 followed on 20 October 2026. When a release is designated LTS, its YY.M base stays fixed for its whole life and only the patch number grows.

Two details matter for anyone writing version comparisons into scripts, policies or SBOM rules:

1. A calendar version does not tell you the track. The manual says release maturity remains an explicit property of each release, recorded in release metadata. Nothing in "26.7.0" says Innovation or LTS.
2. Upgrades follow compatibility lineages. Each calendar versioned release belongs to a lineage anchored by an LTS release base. All Innovation releases before an LTS release, plus the LTS release that closes the sequence, form one lineage. An Innovation release can upgrade within its lineage, including to the LTS release that closes it, but not across a lineage boundary. An LTS release can upgrade within its own line or into the next lineage, but cannot skip one. Only the 9.7.x LTS line can upgrade directly into the first calendar versioned lineage.

If your tooling sorts versions numerically, 26.7.0 sorts above 9.7.4, which happens to match date order. If it assumes the first number is a stable "major version", it will misread the new scheme. Store the track as its own field.

Connectors and tools follow one version number

The manual adds that MySQL Connectors, MySQL Shell, MySQL Router and the MySQL Operator for Kubernetes ship a single release stream using the latest version number, while staying compatible with every supported server version. Its example is Connector/Python 9.7.0, which supports MySQL Server 8.0, 8.4 and 9.x. For supply chain work this is useful: the newest connector is normally the right one for your applications, whichever server track you run, and an old connector pinned in a lockfile is usually just debt.

How do Oracle's quarterly Critical Patch Updates fit?

Oracle publishes security fixes for its products, MySQL included, in Critical Patch Updates (CPUs). Oracle's security alerts page says CPUs are released on the third Tuesday of January, April, July and October, that a pre release announcement appears on the Thursday before each one, and that the next four dates are 19 January 2027, 20 April 2027, 20 July 2027 and 19 October 2027. Each CPU advisory has a MySQL risk matrix listing the CVE identifiers fixed, the affected component, whether the flaw can be exploited remotely without authentication, a CVSS score and the supported versions affected.

MySQL's release calendar is built around the same quarters. In 2026, 9.7.0 shipped on 21 April and 9.7.4 and 26.10.0 on 20 October, both CPU Tuesdays. In July the CPU was on 21 July and the 9.7.2 and 26.7.0 releases followed a week later, on 28 July. Patch releases also appear between quarters (9.7.1 on 16 June, 9.7.3 and 26.7.1 on 18 August). For a CPU listed MySQL flaw, the fix is almost always "move to the release that shipped with or after that CPU".

Three habits follow from this:

• Put the four CPU dates in your patch calendar. A server one CPU behind is missing a quarter of fixes.
• Read the MySQL risk matrix, not just the headline count. Many MySQL entries need an authenticated, privileged user; a few do not. The "remote exploit without authentication" column is the fastest triage signal.
• Treat MySQL 8.0 as unfixed from now on. Oracle's support document says Sustaining Support does not include new updates, fixes, security alerts or Critical Patch Updates. MySQL's EOL notice says 8.0 has been under Sustaining Support since 21 April 2026 and encourages users to upgrade to 8.4 LTS or 9.7 LTS.

The live post Is MySQL 8.0 end of life? What to record and where to move covers the inventory and migration side of that change.

How does MariaDB versioning work?

5.x: tracking MySQL

MariaDB's first release lines matched MySQL's numbers so users could tell which MySQL version each one replaced: 5.1 (GA 1 February 2010), 5.2 (10 November 2010), 5.3 (29 February 2012) and 5.5 (11 April 2012). MariaDB's compatibility page says that until MariaDB 5.5, MariaDB versions functioned as a drop in replacement for the equivalent MySQL version, with some limitations.

10.x: the break

After 5.5 the codebases had diverged enough that matching numbers would have been misleading. MariaDB jumped to 10.0 (GA 31 March 2014) and continued through 10.11. The compatibility page says that from 10.0 it is usually still easy to upgrade from MySQL, and that MariaDB 10.2, 10.3 and 10.4 work as limited drop in replacements for MySQL 5.7 as far as InnoDB is concerned, but that the implementation differences grow with each new MariaDB version.

Between long term lines the project shipped releases with much shorter lives. The all releases page shows, for example, the 10.7 to 10.10 lines each receiving stable updates for roughly a year (10.10's first stable release is dated 17 November 2022 and its last, 10.10.7, 14 November 2023), and 11.5 and 11.7 ending after a handful of releases.

The current model: yearly LTS, quarterly rolling releases

The maintenance policy on mariadb.org/about now reads as follows:

• Long term releases (LTS): a new LTS of MariaDB Server is announced every year.
• Community LTS binaries are released for 3 years after the GA date on mariadb.org/download. Critical and security fixes continue for 2 more years as source code releases. For releases up to MariaDB 11.4, community binaries were released for 5 years.
• Enterprise binaries from MariaDB plc are maintained for 5 years, with an extended option to 8 years, after GA.
• Rolling releases are announced quarterly. The policy says they address vulnerabilities, fix bugs and carry the latest features, and they correspond to the main branch of the MariaDB server repository.

The version number now has defined meanings. In a.b.c, "a" is the major series and, starting with MariaDB 12, is expected to grow yearly. "b" is the minor version and grows quarterly; for each major series, the minor version with the largest "b" becomes the LTS branch. "c" is the patch level, with bug fix releases scheduled quarterly. Patch versions (such as 11.4.4) only fix security issues and bugs; minor versions add functionality while staying backwards compatible; major series may break compatibility.

That is why MariaDB 12.3, GA on 28 May 2026, is the long term line for the 12 series, while 13.0 (May 2026) and 13.1 (September 2026) are rolling releases with community end of life dates of Q4 2026 and Q1 2027.

Note what the table implies: 11.8's community window is shorter than 11.4's, even though it is a year newer. If you use community binaries, plan your next LTS jump on a three year clock, not five.

Where MariaDB diverged from MySQL

The differences are substantial. From MariaDB's own documentation:

• Aria storage engine. Aria is described as a crash safe alternative to MyISAM, with transactional capabilities and improved caching.
• Galera Cluster. MariaDB ships Galera based synchronous replication; its Galera guide lists which Galera library version was released with which MariaDB versions. MySQL's own high availability path is different.
• Account storage. From MariaDB 10.4, all accounts, passwords and global privileges live in mysql.global_priv; mysql.user remains as a view over it, with the same columns. MariaDB's 10.4 authentication page says complex authentication rules did not fit the rigid structure of the old table.
• Authentication plugins. MariaDB has unix_socket, ed25519 and PARSEC, and still supports mysql_native_password. To aid migrations from MySQL, it added a MySQL compatible caching_sha2_password plugin in Community Server 11.4.9, 11.8.4 and 12.1.
• GTIDs. MariaDB's global transaction ID is not compatible with MySQL's, which limits replication topologies that mix the two.
• JSON. MariaDB stores JSON as normal TEXT or BLOB, following the SQL standard, rather than MySQL's binary JSON format. The -> and ->> operators MySQL has had since 5.7 arrive in MariaDB 13.1.
• Encryption at rest. The compatibility page notes that MariaDB 10.1's InnoDB encryption is implemented differently from MySQL 5.7's.
• Data dictionary. MySQL 8.0 introduced a transactional data dictionary; before that, MySQL kept dictionary data in metadata files and non transactional tables. MariaDB did not adopt MySQL's data dictionary.

How did authentication evolve?

Authentication is where this history carries the most security weight. It decides what a stolen copy of the account table is worth to an attacker, and what a captured login reveals.

From the pre 4.1 scheme to mysql_native_password

MariaDB's ed25519 documentation sums up the starting point: MySQL has used SHA-1 based authentication since version 4.1, through the plugin called mysql_native_password, and SHA-1 is no longer considered as secure as it was in 2001. The even older pre 4.1 scheme survives in MariaDB's plugin list as mysql_old_password, which is mainly useful as a warning sign if you find it in an account table.

sha256_password and caching_sha2_password in MySQL

MySQL's first step away from SHA-1 was the sha256_password plugin, which is now deprecated. The 8.0 "What is new" page explains its successor: caching_sha2_password implements SHA-256 password hashing like sha256_password, but uses caching to address connection latency, supports more transport protocols, and does not require linking against OpenSSL for RSA key pair based password exchange.

The 8.0.4 release notes then made it the default. The notes say that, because of its "superior security and performance characteristics", caching_sha2_password became the preferred and default authentication plugin rather than mysql_native_password, and that the change affected both the server (default_authentication_plugin) and the libmysqlclient client library.

The 8.4 manual sets the operating rules. Clients using caching_sha2_password must connect over a secure connection, or over an unencrypted connection that supports password exchange using an RSA key pair. On the server side an in memory cache allows faster reauthentication of users who have connected before. MySQL 8.4 client programs use caching_sha2_password by default.

mysql_native_password: deprecated, disabled, removed

The retirement took three steps:

1. MySQL 8.0: deprecated.
2. MySQL 8.4.0 (30 April 2024): the release notes say the deprecated plugin "is now disabled by default". It can be turned back on with the mysql_native_password=ON setting in the [mysqld] section of the server configuration. The 8.4 manual describes what disabled means: accounts that use it get an access denied error (1045) when they try to connect, and creating or altering an account to use it fails with error 1524, "Plugin 'mysql_native_password' is not loaded".
3. MySQL 9.0.0 (1 July 2024): the plugin is removed. The release notes say the server now rejects native authentication requests from older client programs that lack the CLIENT_PLUGIN_AUTH capability. The client side plugin stays, converted to a dynamically loadable plugin, so new clients can still connect to older servers. The same notes add that MySQL Configurator on Windows detects a root account still using the removed plugin and prompts to convert it to caching_sha2_password before upgrading.

In practice, an account still on mysql_native_password cannot log in to MySQL 9.x or 26.x at all, and cannot log in to 8.4 unless someone switched the plugin back on.

MariaDB: unix_socket, ed25519 and PARSEC

MariaDB took a different route.

• unix_socket. MariaDB's documentation says the unix_socket plugin is installed by default and used by 'root'@'localhost' by default. From 10.4, the root account that mariadb-install-db creates has two methods: first unix_socket, which lets the operating system root user log in over the local socket without a password, and then mysql_native_password with an invalid password set initially, so password login works only after someone deliberately sets one.
• ed25519. The ed25519 plugin uses elliptic curve signatures, the same algorithm OpenSSH uses, to store and verify passwords. The library ships with MariaDB but is not installed by default; you load it with INSTALL SONAME 'auth_ed25519'.
• PARSEC. "Password Authentication using Response Signed with Elliptic Curve" is available from MariaDB 11.6. The documentation describes salted passwords, PBKDF2 key derivation with stored parameters (hash function, iteration count, salt), an extensible storage format and scrambles from both server and client, with the response signed using stock ed25519. MariaDB says PARSEC is intended to become the default in a future release.
• Multiple methods per account. Since 10.4 an account can have more than one authentication plugin, which MariaDB suggests using to migrate users gradually to ed25519.

If you run one application against both databases, the authentication plugin is usually the first thing that breaks.

How did TLS defaults and require_secure_transport change?

MySQL: from optional to preferred

MySQL 5.7.8 added require_secure_transport. The release notes describe it as letting administrators require every client connection to use some form of secure transport: TCP/IP with SSL, a Unix socket file, or shared memory on Windows. The MySQL 8.4 system variable reference still lists its default value as OFF, so the server accepts unencrypted TCP clients until you change it.

On the client side, the 8.4 manual explains that MySQL client programs try an encrypted connection by default if the server supports one, and fall back to unencrypted if they cannot establish it. That is the same behaviour as --ssl-mode=PREFERRED. REQUIRED fails without encryption, and VERIFY_CA or VERIFY_IDENTITY also check the server certificate, which is what defends against impersonation. The live post on MySQL require_secure_transport and VERIFY_IDENTITY walks through the configuration.

MySQL: protocol versions

MySQL 8.0.28 ended TLSv1 and TLSv1.1 for MySQL connections: the release notes say clients that set those protocols cannot make a TLS connection, and TCP connections fail with an error. In 8.4, tls_version and admin_tls_version default to TLSv1.2,TLSv1.3; if the SSL library the server is linked against is older than OpenSSL 1.1.1, TLSv1.3 drops out of the default and the default becomes TLSv1.2.

MariaDB 11.4: TLS by default

MariaDB's documentation on securing connections says that from 11.4 MariaDB encrypts data between server and clients by default unless they run on the same host; before that, the default was unencrypted. Certificates are generated at startup and kept only in memory. Client side certificate verification is on by default, and with a self generated certificate the client can verify it when the authentication plugin is safe against man in the middle attacks (the documentation lists mysql_native_password, ed25519 and PARSEC). You can still install a CA signed certificate, and per account rules such as REQUIRE SSL and REQUIRE X509 force TLS or client certificates for specific users.

Side by side: release line, dates and key security change

Supply chain view: where MySQL and MariaDB versions hide

A database server is rarely one thing you installed once. Versions end up in several places, and each needs its own owner:

• Server packages on hosts. Distribution packages carry the distribution's version and backports, not always the upstream patch level. Check the package changelog as well as VERSION().
• Container images. Database images bake in a specific mysqld or mariadbd. A floating tag can move from one track to another when a new release lands, so check what each tag resolves to, and pin the track you intend.
• Client libraries in applications. Connectors for Java, Python, Node.js, Go, .NET and PHP sit in lockfiles and SBOMs. These decide whether caching_sha2_password, ed25519 or PARSEC work, and whether certificate verification happens.
• Embedded client libraries. libmysqlclient and MariaDB Connector/C are linked into other software, including language runtimes and tools, and appear as transitive components.
• Managed services. A hosted database follows the provider's version and maintenance schedule. You still own the connector, the account plugins and the TLS settings on your side.

An SBOM that records the connector name and version, and image scans that record the server version, turn "are we on a supported line?" into a query rather than a hunt.

Step by step: check what you run and move to modern defaults

The first three steps are read only. Steps 4 and 5 change credentials and connection rules: run them against a test copy first, take a backup, and coordinate with the application owners before you touch production.

Step 1: find the server version and track

SELECT VERSION();
SHOW VARIABLES LIKE 'version%';

On MySQL, version_comment usually names the edition and licence (for example "MySQL Community Server - GPL"). On MariaDB, VERSION() returns a string ending in -MariaDB. For MySQL, record the track as its own field: 8.4.x and 9.7.x are LTS, and 26.x releases need the release notes or your repository configuration to tell you which track they are on.

From a shell, for hosts and images:

mysqld --version
mariadbd --version
docker run --rm mysql:8.4 mysqld --version

Step 2: list accounts by authentication plugin

On MySQL:

SELECT user, host, plugin
FROM mysql.user
ORDER BY plugin, user, host;

On MariaDB 10.4 and later, the plugin is stored in the JSON column of mysql.global_priv:

SELECT user, host,
       JSON_VALUE(priv, '$.plugin') AS plugin
FROM mysql.global_priv
ORDER BY plugin, user, host;

Any MySQL row with mysql_native_password blocks an upgrade to 9.7 and is a warning on 8.4. Any row with mysql_old_password on MariaDB needs attention now. Note any root row whose host is not localhost.

Step 3: check connector support before you switch

Before converting an application account, confirm that its client library supports the target plugin. Current MySQL connectors support caching_sha2_password. Older connectors may not, or may need TLS or the server's RSA public key to complete the first login after a server restart, when the cache is empty. Find the connector and its version in your manifests, lockfiles or SBOM:

grep -RniE "mysql|mariadb" package.json requirements*.txt pyproject.toml pom.xml build.gradle go.mod composer.json 2>/dev/null

Step 4: move accounts off mysql_native_password

On MySQL 8.0 or 8.4, set the new plugin and a new password per account:

ALTER USER 'app'@'10.0.%' IDENTIFIED WITH caching_sha2_password BY 'replace-with-a-long-random-password';

On MariaDB, install ed25519 once and convert accounts (or use PARSEC on 11.6 and later):

INSTALL SONAME 'auth_ed25519';
ALTER USER 'app'@'10.0.%' IDENTIFIED VIA ed25519 USING PASSWORD('replace-with-a-long-random-password');

Then review where root can log in from:

SELECT user, host FROM mysql.user WHERE user = 'root';

Step 5: require TLS

On MySQL, in the server configuration:

[mysqld]
require_secure_transport = ON
tls_version = TLSv1.2,TLSv1.3

Or at runtime, persisted across restarts:

SET PERSIST require_secure_transport = ON;

Then make clients verify the server's identity:

mysql --ssl-mode=VERIFY_IDENTITY --ssl-ca=/etc/mysql/ca.pem -h db.internal -u app -p

On MariaDB 11.4 and later, TLS for non local connections is on by default. To enforce it per account, and on older lines, use account level requirements:

ALTER USER 'app'@'10.0.%' REQUIRE SSL;

Step 6: check the upgrade before you run it

For MySQL, MySQL Shell's upgrade checker (util.checkForServerUpgrade()) reports what will break before you move to a newer release. The command line form from the MySQL Shell manual:

mysqlsh -- util check-for-server-upgrade { --user=root --host=localhost --port=3306 } --target-version=8.4.0 --output-format=JSON --config-path=/etc/mysql/my.cnf

Run it once per hop: for example from 8.0 to 8.4, then from 8.4 to 9.7. It reports removed plugins, reserved word clashes, removed system variables and other incompatibilities.

For MariaDB, after installing the new binaries, run:

mariadb-upgrade --user=root

MariaDB's documentation describes mariadb-upgrade (formerly mysql_upgrade) as a tool that checks and updates your tables to the latest version, and says to run it after upgrading from one major MariaDB release to another. It is not a pre flight checker in the way MySQL Shell's utility is, so read the release notes for the target line and test on a copy first.

Common mistakes

• Treating MariaDB as a drop in for MySQL 8.0 or later. MariaDB's own compatibility page limits drop in behaviour to 5.5 and earlier, with limited InnoDB compatibility for MySQL 5.7. Authentication plugins, account storage, JSON storage and GTIDs all differ. Test in both directions.
• Old connectors that cannot use caching_sha2_password. A connector from before MySQL 8.0 can fail at login once accounts move to the new plugin, or fail only on the first connection after a server restart because the cache is empty and the client cannot do the RSA exchange.
• Re enabling mysql_native_password on 8.4 and forgetting it. It works today and blocks the move to 9.7 later. Track it as debt with an owner and a date.
• Skipped quarterly updates. MySQL fixes land with each CPU. Missing two quarters means half a year of known, fixed vulnerabilities.
• Running 8.0 as if it were still patched. Sustaining Support excludes new fixes and CPUs. Nothing new arrives for 8.0 from Oracle.
• Root reachable over TCP. A root account with a wildcard host and a password gives anyone who reaches the port a target. Keep root local, use unix_socket on MariaDB, and give each application its own narrowly scoped account. The live post on MySQL roles and least privilege application accounts shows a pattern, and the database hardening checklist covers the wider settings.
• Assuming 8.0.x point releases were patch only. They carried features and default changes; treat any 8.0 to 8.4 move as a real upgrade and run the checker.
• Reading 26.x as "version 26". It is a date. Use the release notes and the repository track to decide whether a release is LTS.
• Planning MariaDB on a five year clock. Community binaries for 11.8 and later run for three years after GA.

FAQ

Is MySQL 8.0 end of life?

Oracle's lifetime support document lists MySQL 8.0 premier support ending April 2025 and extended support ending April 2026. MySQL's EOL notice says 8.0 has been under Sustaining Support since 21 April 2026, and Sustaining Support does not include new fixes or Critical Patch Updates. Oracle encourages upgrading to 8.4 LTS or 9.7 LTS.

What is the difference between MySQL LTS and Innovation releases?

LTS releases (8.4, 9.7) contain only necessary fixes, have no removals inside the line, and follow 5 years of premier and 3 years of extended support. Innovation releases add features and can change or remove behaviour, and each is supported only until the next Innovation release. Both include security fixes and are production grade.

Why is the latest MySQL version 26?

From July 2026 MySQL uses calendar versions in YY.M.P format. 26.7.0 was the July 2026 release and 26.10.0 the October 2026 release. 9.7 was the last sequentially numbered line.

When was mysql_native_password removed from MySQL?

It was deprecated in MySQL 8.0, disabled by default in 8.4.0 (30 April 2024) and removed from the server in 9.0.0 (1 July 2024). The client side plugin still exists so new clients can reach older servers. MariaDB still supports it.

Is MariaDB compatible with MySQL?

Partly. MariaDB's compatibility page says versions up to 5.5 were drop in replacements for the equivalent MySQL version, and that 10.2 to 10.4 were limited drop in replacements for MySQL 5.7 as far as InnoDB is concerned. Later versions differ more. Test before moving in either direction.

Who owns MariaDB?

The MariaDB Foundation, a non profit, runs mariadb.org and governs MariaDB Server; its board includes founding, organisational and individual directors. MariaDB plc is the separate commercial company that sells MariaDB Enterprise Server and support.

How often does MySQL release security fixes?

Quarterly, in Oracle's Critical Patch Updates on the third Tuesday of January, April, July and October. MySQL releases ship on or close to those dates, with occasional patch releases in between.

How long are MariaDB long term releases supported?

Community binaries are released for 3 years after GA, with 2 more years of source only critical and security fixes. Lines up to 11.4 got 5 years of community binaries. Enterprise support runs 5 years, with an extended option to 8.

Does MySQL require TLS by default?

No. MySQL clients try TLS first and fall back if it fails, but the server's require_secure_transport defaults to OFF in MySQL 8.4. Turn it on, and use VERIFY_IDENTITY in clients.

Can I upgrade directly from MySQL 8.0 to 9.7?

The manual says LTS series cannot be skipped. The safe route from 8.0 is to 8.4 first and then to 9.7, running MySQL Shell's upgrade checker before each hop. Check the manual's "Upgrade Paths" section for your exact versions.

Where Safeguard fits

Safeguard does not patch database servers, manage MySQL or MariaDB accounts, or audit your my.cnf; the SQL in the walkthrough above does that. The fit is the software around the database. Applications pull MySQL and MariaDB connectors, container images bake in a specific server build, and SBOMs record what shipped. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, shows which projects contain a given component and version, and can open fix pull requests when a fixed version exists (autonomous remediation ships switched off). It will not tell you that an account still uses mysql_native_password.

That supply chain angle is real for both databases. The connector version and the server image tag are the two pieces most teams forget between quarterly MySQL releases and MariaDB's quarterly updates, and both live in code you build and ship. Here is how Safeguard helps close those gaps, both when a fix exists and while one does not.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. The assistant reads a finding and its advisory in a repository, asks before any command that changes something, edits a dependency version and runs the install and tests. The same flow fits a MySQL or MariaDB connector upgrade in an application repository, or a Dockerfile that still pins a MySQL 8.0 image.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That is a practical way to scan database and application images in your build environment after each quarterly MySQL release or MariaDB update, before they reach a registry.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. With that connection you can ask which of your projects contain a given connector version, answered from your own Safeguard data.

Click through it at your own pace, or open it full screen.

To try it on your own repositories and images, download Safeguard or read the CLI documentation. For the same kind of history on the other big open source database, see the PostgreSQL release history.

Quick check

Sources

• MySQL 8.4 Reference Manual: MySQL Releases, Innovation and LTS
• MySQL 26.10 Reference Manual: MySQL Releases and version numbers
• MySQL 8.4 Reference Manual: History of MySQL
• Oracle Lifetime Support Policy: Oracle Technology Products (PDF)
• MySQL Product Support EOL Announcements
• Sun Microsystems: Sun announces agreement to acquire MySQL (16 January 2008, archived)
• Oracle: Oracle buys Sun (press release, 20 April 2009)
• Oracle: Oracle completes acquisition of Sun (27 January 2010, archived)
• Oracle Critical Patch Updates, Security Alerts and Bulletins
• MySQL 8.4 Release Notes
• MySQL 9.7 Release Notes
• MySQL 26.10 Release Notes
• Changes in MySQL 8.4.0
• Changes in MySQL 9.0.0
• Changes in MySQL 8.0.4
• Changes in MySQL 8.0.28
• Changes in MySQL 5.7.8
• What Is New in MySQL 8.0
• MySQL 8.4: Caching SHA-2 Pluggable Authentication
• MySQL 8.4: Native Pluggable Authentication
• MySQL 8.4: Using Encrypted Connections
• MySQL 8.4: Server System Variables
• MySQL 8.4: Changes in MySQL 8.4 (upgrading)
• MySQL Shell: Upgrade Checker Utility
• MariaDB Foundation: About MariaDB Server and maintenance policy
• MariaDB Foundation: MariaDB Server, all releases
• MariaDB Foundation: achievements 2012-12 to 2013-09
• MariaDB: MariaDB versus MySQL compatibility
• MariaDB: Authentication from MariaDB 10.4
• MariaDB: mysql.global_priv table
• MariaDB: Authentication plugin ed25519
• MariaDB: Authentication plugin PARSEC
• MariaDB: Authentication plugin caching_sha2_password
• MariaDB: Authentication plugin unix_socket
• MariaDB: Securing connections for client and server
• MariaDB: Aria storage engine
• MariaDB: Galera Cluster guide
• MariaDB: mariadb-upgrade

Last reviewed: 25 October 2026. MySQL releases follow Oracle's quarterly patch dates and MariaDB publishes quarterly updates; check the linked release notes and support pages for the latest versions.