MySQL-compatible databases in 2026: revisit MySQL, MariaDB and Percona Server before you upgrade another database

Most teams that run MySQL do not choose their database every year. They chose it once, long ago, and since then they have only upgraded it, or not upgraded it. In 2026 that habit is being tested. MySQL 8.0, the version most production systems still run, moved to Oracle Sustaining Support in April 2026, which means no new fixes. MySQL itself has changed its release model twice in three years. MariaDB now has a new long-term release every year. Percona has stopped regular releases for its 8.0 line. And the people who build tools around MySQL have started a foundation of their own because they are worried about where Oracle is taking the project.

So when a team says “we need to upgrade MySQL”, the real question is wider: upgrade to what, and with whom? This post compares the three servers most teams actually weigh for a self-managed MySQL-style database in 2026: Oracle MySQL Community Edition, MariaDB Server and Percona Server for MySQL. We look at where each one stands on 27 October 2026, how far they have drifted apart, what that drift means for replication, backups, high availability and support, and we work through a plan for one invented team that has to move off MySQL 8.0 this year.

A few earlier posts sit next to this one. In distributed SQL with CockroachDB, YugabyteDB and TiDB we looked at what to do when one primary is no longer enough; this post stays with the single primary and its replicas. In schema migrations with Atlas, Flyway and Liquibase we looked at how schema changes reach production, and a server upgrade is a good moment to check that those tools understand your new version. In change data capture with Debezium, Flink CDC and PeerDB we looked at reading the binary log, which is exactly the part that differs most between these servers. And file backups with restic, BorgBackup and Kopia covers where your database backup files should finally live.

A scenario to keep us honest

Take an invented Vijayawada company that builds dealer management, spare parts billing and service booking software for two-wheeler and tractor dealers in Andhra Pradesh and Telangana. About 22 engineers. The product is a PHP and Laravel application for dealers, a Java service for GST invoices and e-way bills, a Go service that sends service reminders over SMS and WhatsApp, and a reporting module that dealers use at month end.

Their database estate looks like this:

• The main database is MySQL 8.0.36 Community on three virtual machines: one primary and two asynchronous replicas with GTID on. Failover is a runbook and a phone call.
• The reporting module runs on a separate MariaDB 10.6 server that a former engineer set up because “it is the same thing and it was already in the Ubuntu repository”. It is filled every night by a script that runs mysqldump on a MySQL replica and loads the file into MariaDB.
• Backups are a nightly mysqldump of the primary, compressed and copied to object storage. Nobody has restored one in full since 2024.
• The application user still logs in with mysql_native_password, because an old PHP library could not handle caching_sha2_password when the system was built.
• Some invoice tables store e-way bill responses in JSON columns, and one report uses the ->> operator.

Two things set off the current discussion. First, an auditor from a large dealer group asked for the support status of every component, and the answer for MySQL 8.0 and MariaDB 10.6 was “past end of life”. Second, the nightly reporting load failed for three nights in a row after someone added a JSON column on the MySQL side, and the dealers’ month-end reports were late.

After the audit, one developer proposed moving everything to MariaDB (“fully open source, one database, the reporting server already works”). Another proposed MySQL 9.7 (“latest LTS, Group Replication features are now free”). The database lead, who reads the Percona blog, asked whether Percona Server would give them the same MySQL with better tools.

The question this post tries to answer: which server should this team run for the next few years, and what has to change apart from the version number?

The short version

• MySQL Community Edition (GPLv2, owned by Oracle) now has two kinds of releases: LTS lines with long support and Innovation releases every quarter. The current LTS lines are 8.4 (latest 8.4.13) and 9.7 (latest 9.7.4). From mid 2026 Oracle moved to calendar version numbers: 26.10.0 is the newest Innovation release, and the next LTS is planned as 28.4, in April 2028. MySQL 8.0 has been in Sustaining Support since 21 April 2026, with 8.0.46 as its last release.
• MariaDB Server (GPLv2, developed by MariaDB plc and the MariaDB Foundation) started as a fork of MySQL in 2009 and has been its own database for years. It has a yearly LTS release with three years of community support, plus quarterly rolling releases. The newest LTS is 12.3 (latest 12.3.3), supported until June 2029. The newest stable rolling release is 13.0. MariaDB 10.6 reached community end of life on 6 July 2026.
• Percona Server for MySQL (GPLv2, by Percona) is MySQL with extra features that Oracle keeps for its Enterprise Edition, such as a thread pool, audit logging and data masking, plus its own backup tool, Percona XtraBackup. Percona follows only the LTS lines: 8.4 (latest 8.4.11-11) and 9.7 (first release 9.7.1-1 in August 2026, latest 9.7.2-2). Percona Server 8.0 reached end of life on 1 April 2026.
• Percona Server is a close copy of MySQL and can replace it in place. MariaDB is not a drop-in replacement for MySQL 8.0 or later. GTIDs, JSON storage, default collations, authentication plugins, binary log details and backup tools are all different.
• For the Vijayawada team, the plan in this post is: move the main database to the 8.4 LTS line first (MySQL or Percona, same data files), fix backups and test a full restore before the upgrade, decide on high availability as a separate step, stop the fragile MySQL to MariaDB nightly copy, and plan 9.7 for later rather than jumping two LTS lines at once.
• Neither trigger was caused by the choice of vendor. One was an upgrade that nobody scheduled, and one was a hidden dependency between two databases that only looked the same.

Where things stand on 27 October 2026

All times below are converted to IST. Dates come from official release notes, lifecycle pages and vendor announcements.

Oracle MySQL

• Release model. Since MySQL 8.1 (July 2023), Oracle has published Innovation releases every quarter and LTS releases about every two years. Innovation releases are supported only until the next one. LTS lines get five years of Premier Support and three years of Extended Support. New features and removals land in Innovation releases and in the first release of an LTS line; after that, an LTS line gets fixes only.
• 8.0. As of 21 April 2026 MySQL 8.0 is covered by Oracle Sustaining Support, which gives access to existing releases and knowledge but no new fixes or updates. The last release is 8.0.46. Oracle asks users to move to 8.4 LTS or 9.7 LTS. For HeatWave, Oracle’s managed service, existing 8.0 instances get critical security patches until April 2027 and are then upgraded to 8.4 LTS automatically.
• 8.4 LTS. First released on 30 April 2024. Latest is 8.4.13, released on 20 October 2026. Premier Support runs to April 2029 and Extended Support to April 2032.
• 9.7 LTS. 9.7.0 was released on 21 April 2026. Since then: 9.7.1 (16 June), 9.7.2 (28 July), 9.7.3 (18 August, a Critical Security Patch Update) and 9.7.4 (20 October 2026). Premier Support runs to April 2031 and Extended Support to April 2034.
• Community features in 9.7. With 9.7.0, Oracle moved several capabilities from Enterprise to Community, including Group Replication flow control monitoring, automatic eviction and rejoin of members, primary election that prefers the most up-to-date member, extended statistics for the multi-threaded replica applier, telemetry through OpenTelemetry, JSON Duality Views and the Hypergraph optimizer. Dynamic Data Masking was added to Enterprise.
• Calendar versions. In June 2026 Oracle announced that 9.7 is the last line with the old numbering. New versions use a YY.M format. 26.7.0 came out on 28 July 2026 and 26.10.0 on 20 October 2026, both Innovation releases. Oracle has published planned versions 27.1, 27.4, 27.7, 27.10 and 28.1, with 28.4 as the next LTS in April 2028. Critical Patch Updates stay quarterly, with security patch updates as needed.
• What 26.10.0 added. The MySQL REST Service became a server component (HTTPS on port 33443 by default), and the Health Monitor and WebAuthn authentication became available in Community. The release notes credit contributions from Percona, Amazon, Alibaba and Tencent, among others.
• Platforms. Oracle stopped building MySQL binaries for Enterprise Linux 7 for all series (notice of 4 August 2026) and for Solaris (29 September 2026).
• Upgrade paths. Oracle’s documentation does not allow skipping an LTS line. From 8.0 you go to 8.4, and from 8.4 to 9.7 or later. In-place upgrade, dump and load, and replication are all supported methods.

Governance around MySQL

• In September 2025 The Register reported layoffs in Oracle’s MySQL team. In February 2026 Percona co-founder Vadim Tkachenko published an open letter asking Oracle to change how MySQL is run; the letter gives Percona’s own estimate of how much the team had shrunk.
• On 27 May 2026 the OurSQL Foundation was launched as a US trade association for the MySQL ecosystem, with people from Percona, PlanetScale, PingCAP and others on its board. Oracle is not a member.
• In June 2026 Oracle announced a new governance model for MySQL, with committers and a technical steering committee that includes AWS, Google Cloud and Oracle. Critics such as Peter Zaitsev pointed out that nothing in it is binding. It is too early to judge how it works in practice.

MariaDB

• Release model. One LTS release a year. From 12.3 onwards, the “.3” release of each major version is the LTS. Community binaries are supported for three years (older LTS lines up to 11.4 had five years), followed by two years of source-only critical fixes. Between LTS releases there are quarterly rolling releases, each supported until the next one.
• LTS lines. 10.6 reached community end of life on 6 July 2026. Still supported: 10.11 (until 16 February 2028, latest 10.11.19), 11.4 (until 29 May 2029, latest 11.4.13), 11.8 (until 4 June 2028, latest 11.8.9) and 12.3, which became GA with 12.3.2 on 28 May 2026 and is maintained until June 2029. The latest is 12.3.3, released on 24 August 2026 together with 11.8.9, 11.4.13 and 10.11.19.
• What 12.3 changes. innodb_snapshot_isolation is now on by default, which changes how some REPEATABLE READ transactions behave under conflict: test this before you upgrade. It also brings binary log improvements, an XML data type, Oracle-style TO_DATE and an IS JSON predicate. MariaDB plc’s own blog claims large write performance gains for 12.3; treat that as the vendor’s claim until you measure your own workload.
• 13.0. 13.0.2 became the stable rolling release on 15 September 2026. It adds single-table UPDATE ... RETURNING with OLD_VALUE(), a query block name hint, a new InnoDB log archive option (which mariadb-backup does not support yet), and a DuckDB storage engine at gamma maturity.
• Ownership. MariaDB plc was taken private by K1 Investment Management in 2024. The MariaDB Foundation is a separate non-profit that looks after the open source project. The server stays GPLv2.
• MaxScale. MariaDB’s proxy is not open source. Versions up to 24.08 use the Business Source License, free for fewer than three database servers, with each version converting to GPL on its change date. From 25.01 (January 2025) it is under a proprietary commercial licence.

Percona

• Percona Server for MySQL 8.4. First release 8.4.0-1 on 28 August 2024; latest 8.4.11-11 on 20 August 2026. Percona has extended its support for 8.4 to 30 April 2032.
• Percona Server for MySQL 9.7. Percona does not ship 9.x Innovation releases. It skipped 9.7.0 and started with 9.7.1-1 on 5 August 2026. 9.7.2-2 followed on 28 September 2026 with OpenID Connect authentication (JWT tokens, mapping identity provider groups to roles), vector distance functions and InnoDB buffer pool improvements. It did not release 9.7.3, because that Oracle security update did not affect Percona’s build. Percona lists 9.7 support to April 2034.
• Percona Server 8.0 reached end of life on 1 April 2026. Percona offers paid post-EOL support, and 8.0 packages moved to a private repository.
• Tools. Percona XtraBackup 8.4 is GA (latest 8.4.0-7, 17 September 2026). XtraBackup for 9.7 was still a release candidate when we checked. Percona XtraDB Cluster (Galera based) has an 8.4 GA release; 9.7 is not out yet. The Percona Operator for MySQL based on Percona Server went GA in November 2025. Percona Monitoring and Management (PMM) is on version 3.

Tools around all three

• mydumper, the parallel logical backup tool, reached its first stable LTS release, 1.0.1, on 17 May 2026. The latest release is 1.0.11-1, from 8 October 2026.
• Orchestrator, the replication topology and failover tool, was archived by its original maintainers in 2025. On 9 April 2026 ProxySQL announced that it has taken over maintenance, and that it stays under the Apache 2.0 licence.

First question: why do you want to change?

Before you compare vendors, write down the real reason. The common ones, and what each one actually needs:

• “Our version is out of support.” This needs an upgrade within the same family first. Moving MySQL 8.0 to 8.4 is a supported, well-documented path. Moving MySQL 8.0 to MariaDB is a migration, with application testing. Do not turn an overdue upgrade into a migration project unless you have another strong reason.
• “We want features that are Enterprise-only in Oracle MySQL.” Thread pool, audit logging, data masking, encryption key management with a vault: Percona Server gives you most of these in the same MySQL code base. MariaDB has its own versions of several of them.
• “We do not trust Oracle’s direction.” This is a fair worry in 2026, but be honest about what it changes. Percona Server still follows Oracle’s code, so if Oracle slows down, Percona slows down too. MariaDB is independent of Oracle, but it is a different database with its own owner.
• “We want one database engine everywhere.” Good goal, but pick the engine that the main application needs. In our scenario, the main application is a MySQL application. The reporting server should follow it, not the other way round.
• “We want better performance.” First check what is slow. Most MySQL performance problems are queries, indexes, buffer pool size and connection handling. Changing vendor rarely fixes those.
• “We want easier high availability.” This is really a choice between Group Replication or InnoDB Cluster, Galera, and asynchronous replication with a failover tool. It is a separate decision from the vendor, though the vendor limits which options you have.

The Vijayawada team had two real reasons: support status, and a broken copy between two databases that only look alike. Neither one needs a change of vendor.

What each tool is

Oracle MySQL Community Edition

The original. Oracle has owned it since it bought Sun Microsystems in 2010. Development happens inside Oracle; the source is published on GitHub with each release, and outside contributions are accepted under Oracle’s contributor agreement. The Community Edition is GPLv2. The Enterprise Edition adds the thread pool, Enterprise Audit, Enterprise Backup, data masking, firewall and other features under a commercial licence and support contract. MySQL Shell, MySQL Router and InnoDB Cluster (built on Group Replication) are the official tools for dumps, upgrades checks and high availability.

MariaDB Server

Started in 2009 by Michael “Monty” Widenius, one of MySQL’s original authors, as a fork when Oracle’s purchase of Sun was pending. For the first few years it followed MySQL closely. From 10.0 onwards it went its own way, and today it has its own optimizer work, its own GTID design, its own JSON handling, system versioned tables, sequences, Oracle compatibility features, the Galera cluster built into the server, and many storage engines. MariaDB plc sells support and enterprise products; the MariaDB Foundation looks after the community project and its release process.

Percona Server for MySQL

Percona has offered an enhanced build of MySQL since around 2008. It tracks Oracle’s MySQL closely, adds features and fixes, and stays compatible at the data file level, so you can switch between MySQL and Percona Server of the same version in place. Its extras include a thread pool, an audit log filter component, data masking, key management integration, extra diagnostics and, in 9.7, OpenID Connect authentication. Around it Percona maintains XtraBackup, Percona XtraDB Cluster, Percona Toolkit, PMM and Kubernetes operators, all open source. Percona sells support, not licences.

Side by side

Licence and ownership

• MySQL: GPLv2 Community Edition, owned and developed by Oracle. Enterprise features are closed source.
• MariaDB: GPLv2 server. MariaDB plc is privately owned by K1; the MariaDB Foundation is a separate non-profit. MaxScale is not open source.
• Percona Server: GPLv2, all extras open source. Percona is a privately held company. Its features depend on Oracle continuing to publish MySQL source.

Release lines and support length

• MySQL: LTS every two years or so (8.4, 9.7, then 28.4), five years Premier plus three years Extended. Innovation releases every quarter, each supported only until the next one.
• MariaDB: LTS every year, three years of community binaries plus two years of source-only critical fixes. Rolling releases every quarter.
• Percona Server: LTS lines only, following Oracle’s, with its own end dates (8.4 to April 2032, 9.7 to April 2034).

Compatibility with MySQL 8.x

• MySQL to Percona Server: same data files, same replication, same client protocol and authentication. Percona adds features; it does not remove MySQL ones.
• MySQL to MariaDB: the wire protocol and much of the SQL are shared, but the systems have different GTID formats, different JSON storage, different default collations (MySQL 8 uses utf8mb4_0900_ai_ci, MariaDB 11.4 and later use utf8mb4_uca1400_ai_ci), different explicit_defaults_for_timestamp behaviour, and different system tables. There is no in-place switch from MySQL 8 data files to MariaDB. You move with a logical dump and load, or with replication under limits.

Replication and GTID

• MySQL and Percona: GTIDs look like server_uuid:transaction_number. Asynchronous and semi-synchronous replication, multi-threaded replicas, and Group Replication.
• MariaDB: GTIDs look like domain-server-sequence, for example 0-1-3. Its own parallel replication. The two GTID formats are not compatible.
• Between them: MariaDB can replicate from MySQL 8.0 only with recent MariaDB versions (10.6.21, 10.11.11, 11.4.5 or later), with binary log compression and partial JSON updates turned off on the MySQL side, and without JSON columns, which MariaDB documentation says must be changed to TEXT. Support for caching_sha2_password on the replication user arrived only in MariaDB 11.4.9, 11.8.4 and 12.1.1. Do not plan replication from MariaDB back to MySQL as a normal setup.

JSON

• MySQL and Percona: a native binary JSON type, partial in-place updates, the -> and ->> operators, multi-valued indexes, and in 9.7 JSON Duality Views in Community.
• MariaDB: JSON is an alias for LONGTEXT with a JSON_VALID check constraint. JSON functions exist and are rich, but the storage is text, the ->> operator does not exist, and you index JSON through generated columns.

High availability

• MySQL: Group Replication and InnoDB Cluster with MySQL Router, and InnoDB ClusterSet for disaster recovery. In 9.7, more of the monitoring and automatic recovery features are in Community.
• MariaDB: Galera Cluster built in, plus asynchronous replication with MaxScale (commercial) or other proxies for failover.
• Percona: Group Replication as in MySQL, plus Percona XtraDB Cluster (Galera based) as a separate product.
• All three: asynchronous replication with Orchestrator and a proxy such as ProxySQL still works, and is what many teams run.

Backup tools

• Logical: mysqldump (MySQL and Percona) and mariadb-dump work everywhere but are slow for large databases. mydumper does parallel dumps and loads for both families. MySQL Shell dump and load utilities are parallel and fast, and are designed for MySQL.
• Physical: Percona XtraBackup for MySQL and Percona Server (use the version that matches your server line). mariadb-backup for MariaDB; it is based on an old XtraBackup fork and does not back up MySQL 8 data. MySQL Enterprise Backup needs an Enterprise subscription. The MySQL Clone plugin can copy a running instance to a new one, which is useful for building replicas.

Thread pool, audit and security extras

• Thread pool: MySQL Enterprise only. Built into Percona Server and MariaDB.
• Audit: MySQL Enterprise Audit. Percona Server has an audit log filter component. MariaDB ships the server_audit plugin.
• Authentication: MySQL 8.4 disables mysql_native_password by default, and MySQL 9.0 removed it. caching_sha2_password is the default. MariaDB still supports mysql_native_password and has its own ed25519 and parsec plugins. Percona Server 9.7.2 adds OpenID Connect.

Performance

• All three publish benchmarks where they look good. Oracle, MariaDB plc and Percona each run their own tests on their own hardware. We have not run any for this post.
• Real differences show up in specific workloads: many short connections (where a thread pool helps), heavy JSON use, analytic queries and write-heavy replication. Measure your own top queries on your own hardware before you believe any number, including ours.

Managed services

• The large cloud providers offer managed MySQL, and AWS also offers managed MariaDB. Each provider has its own version list and end of support dates. If you are moving to a managed service anyway, the vendor question becomes “what does my cloud support, and for how long?”

What actually happens when you upgrade 8.0 to 8.4

An in-place upgrade from 8.0 to 8.4 is simple to type and easy to get wrong. When the 8.4 server starts on 8.0 data files, it upgrades the data dictionary and system tables by itself. What it cannot do is change your application or your settings for you. The common surprises:

• Authentication. mysql_native_password is disabled by default in 8.4. Accounts that use it cannot log in until you either enable the plugin for now or move the accounts to caching_sha2_password. Old client libraries may need an upgrade first.
• Removed and changed settings. Some old options and variables were removed between 8.0 and 8.4. A config file that worked for years can stop the server from starting.
• Changed defaults. Several InnoDB and replication defaults changed. Read the “What is new in 8.4” pages for the settings you rely on.
• Replication terms. Old MASTER and SLAVE statements and variables have been replaced with SOURCE and REPLICA forms. Scripts and monitoring checks need updating.
• Tools. Your backup tool must match: XtraBackup 8.0 does not back up 8.4; you need XtraBackup 8.4.

MySQL Shell’s upgrade checker (util.checkForServerUpgrade()) finds most of these before you start. Run it against a copy of production, not just a test database.

A worked plan for the Vijayawada team

Step 1: Write down what you have

List every MySQL and MariaDB server, its exact version, its configuration file, its users and their authentication plugins, and every client that connects: PHP library version, Java JDBC driver version, Go driver version, and any reporting or BI tool. Note which tables use JSON columns and which queries use -> or ->>.

Step 2: Fix backups and test a restore first

Before you upgrade anything, make sure you can go back. Add a physical backup with Percona XtraBackup 8.0 for the current 8.0 primary, keep the nightly logical dump with mydumper instead of a single-threaded mysqldump, and restore both into a fresh virtual machine. Time the restore. Write the steps down. Keep binary logs long enough to replay from the last backup.

Step 3: Fix authentication and clients while still on 8.0

Upgrade the PHP library, JDBC driver and Go driver to versions that support caching_sha2_password, then move each application user to it, one at a time, on 8.0. This removes the biggest 8.4 surprise before the upgrade day.

Step 4: Pick MySQL 8.4 or Percona Server 8.4

Both run the same data files, so this choice is reversible. Percona Server gives the team a thread pool, an audit log and data masking without an Enterprise contract, which helps with the dealer group’s audit questions. Oracle MySQL is the reference build and has the newest Community features first. For this team, the audit need tips it towards Percona Server 8.4, with the option to switch back later.

Step 5: Upgrade by replication, not on the primary

Build a new 8.4 replica from the 8.0 primary (from a restored backup), let it catch up, run the application test suite and the month-end reports against it, and watch it for a week. Then upgrade the other replica the same way. Switch the primary to an 8.4 server in a planned window. Keep the old 8.0 primary as a replica of the new one only for as long as you need a way back, and remember that replication from a newer to an older version is not a supported long-term setup.

Step 6: Stop the MySQL to MariaDB copy

The reporting server should become a normal 8.4 replica of the main database, or a separate 8.4 server filled with mydumper from a replica. That removes the JSON and collation differences that broke the nightly load. If the team wants to keep MariaDB for reporting, it needs to move it to a supported LTS (11.8 or 12.3) and accept that JSON columns and GTIDs will keep needing special handling.

Step 7: Decide on high availability separately

With the upgrade done, choose one failover approach: Group Replication with MySQL Router or a proxy, or asynchronous replication with Orchestrator and ProxySQL. Practise a failover in a test environment. Do not do this in the same window as the version upgrade.

Step 8: Plan 9.7 for next year

8.4 is supported to 2032, so there is no rush. Plan the 8.4 to 9.7 upgrade after Percona’s XtraBackup 9.7 is GA and after the team has run 9.7 on a test replica for a few weeks. Do not move production to Innovation releases such as 26.10 unless you are ready to upgrade every quarter.

When MariaDB is the better choice

MariaDB is a strong database in its own right. It makes sense when:

• You are starting a new system, or the application has been built and tested on MariaDB already.
• You want features MySQL does not have: system versioned tables, sequences, Oracle compatibility for migrated PL/SQL code, RETURNING clauses, or Galera built into the server.
• You want an engine whose development does not depend on Oracle’s decisions.
• Your Linux distribution ships MariaDB as the default, and you want to stay on distribution packages and security updates.
• You already run Galera and know how to operate it.

Go in with open eyes: treat it as a migration, test every query, replace JSON-specific MySQL syntax, rebuild backups around mariadb-backup, and plan your proxy without assuming MaxScale is free.

When not to change at all

• If you are on MySQL 8.4 or Percona Server 8.4 with tested backups, there is nothing urgent to do in 2026. Support runs to 2032.
• If you are on MariaDB 10.11 or 11.4 and your application works, plan the next LTS upgrade calmly. 10.11 is supported until February 2028.
• If your database is on a managed cloud service that still supports your version, follow the provider’s schedule rather than inventing your own.
• If the main reason to switch is a benchmark blog post, measure first.

A short history, so the choices make sense

• 1995: MySQL AB in Sweden releases MySQL, created by Michael Widenius, David Axmark and Allan Larsson. It becomes the “M” in the LAMP stack.
• 2000s: InnoDB becomes the main transactional engine. Percona starts consulting on MySQL performance and later releases its own enhanced build.
• 2008: Sun Microsystems buys MySQL AB.
• 2009: Oracle agrees to buy Sun. Monty Widenius starts MariaDB as a fork, named after his younger daughter, as MySQL was named after his elder daughter, My.
• 2010: Oracle completes the Sun purchase and becomes the owner of MySQL.
• 2012 onwards: MariaDB moves away from MySQL’s numbering with 10.0 and adds its own features. The MariaDB Foundation is set up to look after the project.
• 2018: MySQL 8.0 arrives with the new data dictionary, window functions, common table expressions and roles. It becomes the most widely used version for years.
• 2023: Oracle introduces Innovation and LTS releases with 8.1.
• 2024: MySQL 8.4 becomes the first LTS line. MariaDB plc is taken private by K1.
• 2025 to 2026: Layoffs in Oracle’s MySQL team are reported, Percona’s open letter is published, the OurSQL Foundation is launched, 8.0 goes into Sustaining Support, 9.7 LTS ships, and Oracle moves to calendar version numbers.

This history explains the choices. Percona follows Oracle because it chose to stay compatible. MariaDB differs from MySQL because it chose not to. And Oracle’s release model is new enough that many teams have not adjusted their upgrade habits to it yet.

Operational costs to plan for

• Upgrade cadence. With LTS lines every two years and eight years of support, one planned major upgrade every two to four years is enough. Budget for it like any other project.
• Backups. Physical backup tools are tied to server lines. Every major upgrade means a new backup tool version, a new restore test and new runbooks.
• Client drivers. Authentication and protocol changes need new drivers. Older applications are the slowest part of every upgrade.
• Monitoring. PMM, Prometheus exporters and cloud monitoring all need to understand the new version and the new variable names.
• People. Somebody must read release notes every quarter, at least for security fixes. That is a small, steady job that is easy to skip.
• Support contracts. Decide whether you need a vendor to call. Oracle sells MySQL Enterprise, MariaDB plc sells MariaDB Enterprise, and Percona sells support for open source builds. Several smaller companies offer support for all of them.

A decision guide

• You run MySQL 8.0 today and the application is a MySQL application: upgrade to 8.4 (MySQL or Percona Server). Then plan 9.7.
• You need Enterprise-style features without an Enterprise contract: Percona Server 8.4 or 9.7.
• You want the newest MySQL features as soon as they ship: Oracle MySQL, and decide whether you can handle quarterly Innovation upgrades or should wait for 28.4.
• You run MariaDB 10.6 or older: upgrade to 11.8 or 12.3 LTS. Read the 12.3 snapshot isolation change first.
• You are starting fresh with no MySQL-specific code: either family works. Pick the one your team, your distribution and your cloud support best.
• One primary is no longer enough: look at Vitess for sharding MySQL, TiDB for a MySQL-compatible distributed database, or a managed service such as PlanetScale, and read our distributed SQL post before you decide.

Checklist before you upgrade

• Exact current versions and their end of support dates are written down.
• A physical and a logical backup exist, and a full restore has been tested and timed.
• Binary logs are kept long enough to recover from the last backup.
• MySQL Shell’s upgrade checker has been run against a copy of production.
• All application users use an authentication plugin that the new version supports.
• Client drivers in every service support the new version.
• Configuration files have been checked for removed options.
• The backup tool version matches the new server line.
• The upgrade happens first on a replica, which runs real traffic or real tests for some days.
• A rollback plan exists, and it is realistic about what cannot be undone.
• Monitoring and alerting work on the new version.
• Schema migration tools and CDC tools that read the binary log have been tested against the new version.

Common mistakes

• Treating MariaDB as “MySQL with another name”. It was close in 2010. It is not in 2026.
• Jumping two LTS lines. 8.0 to 9.7 directly is not a supported path. Go through 8.4.
• Running production on Innovation releases without a plan. Each one is supported only until the next Innovation release, about a quarter later.
• Upgrading the primary first. Upgrade a replica, test it, then switch.
• Forgetting the backup tool. A backup tool that does not support the new version fails quietly on the first night after the upgrade.
• Leaving mysql_native_password until upgrade day. Move users before the upgrade.
• Copying data between MySQL and MariaDB with scripts. It breaks on the first JSON column, collation or GTID difference.
• Believing a vendor benchmark without testing your own workload.
• Assuming MaxScale is free. Check the licence for the version you plan to run.

A small hands-on drill

We ran a small local drill on 27 October 2026, at about 2:25 PM IST, on a Linux 6.12 x86_64 test machine. We installed MariaDB 11.8.6 from Debian 13 packages and ran it as a normal user in a throwaway data directory, listening only on 127.0.0.1 and a local socket, with the binary log on. We did not run Oracle MySQL or Percona Server in this drill, because neither was available from the distribution packages and we kept the drill short.

What we saw:

• Defaults. The server collation was utf8mb4_uca1400_ai_ci, explicit_defaults_for_timestamp was on, and innodb_snapshot_isolation was on.
• JSON. A column created as JSON came back from SHOW CREATE TABLE as longtext with a json_valid() check constraint. Inserting invalid JSON was rejected by that check. JSON_VALUE() worked.
• MySQL syntax. doc->>'$.city' failed with a syntax error. A MySQL-style functional index, INDEX ((CAST(... AS UNSIGNED))), also failed with a syntax error. A new table with COLLATE utf8mb4_0900_ai_ci was accepted.
• GTID. After a few statements the current GTID position was 0-1-3, in MariaDB’s domain-server-sequence format, not MySQL’s UUID format.
• Authentication and audit. mysql_native_password was active. The server_audit plugin installed with one statement and had logging off by default.
• Backups. mariadb-dump --single-transaction worked, and mariadb-backup --backup and --prepare both completed, recording the binary log file, position and GTID.

This is a tiny test, not a benchmark, and it says nothing about performance. It does show, in a few minutes, why the Vijayawada nightly copy broke: the JSON type, the ->> operator, functional indexes and GTIDs are all places where the two families no longer match.

Unlearn, re-learn

Unlearn the idea that MySQL, MariaDB and Percona Server are three names for one database. Percona Server is MySQL with extras. MariaDB is a sister database that has grown up in its own house. Unlearn, too, the habit of treating a database upgrade as something that happens when an auditor asks. Re-learn the database as a product with a lifecycle: a supported LTS line, a backup you have restored, clients that match the server, a replica to test on, a failover you have practised, and a calendar reminder for the next LTS. Pick the server that fits your application and your support needs, which for most MySQL 8.0 shops in 2026 means an 8.4 LTS build first. The vendors and their politics will keep changing; a tested restore will not go out of date.

Sources

• Oracle MySQL: MySQL 8.0 end of life notice and other EOL notices, Oracle Lifetime Support Policy, MySQL release notes, MySQL 8.4 release notes, MySQL 9.7 release notes, MySQL releases: Innovation and LTS and upgrade paths
• Oracle MySQL blog: MySQL 9.7 LTS announcement and the June 2026 post on the new calendar release model
• MySQL governance: reporting by The Register on the 2025 layoffs and the June 2026 governance model, the Percona open letter and the OurSQL Foundation launch announcement
• MariaDB: release and maintenance policy, MariaDB release notes, MariaDB 12.3 LTS announcement, MariaDB versus MySQL compatibility and replication from MySQL
• MariaDB MaxScale: licence information
• Percona: Percona Server for MySQL release notes, Percona release lifecycle, Percona XtraBackup documentation and Percona XtraDB Cluster documentation
• Tools: mydumper releases, ProxySQL takes over Orchestrator and MySQL Shell upgrade checker
• Lifecycle summaries: endoflife.date for MySQL and endoflife.date for MariaDB
• Nearby options: Vitess, TiDB and PlanetScale