TL;DR Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates. To encourage broader adoption of secure and supported database versions, WordPress should clarify that only LTS releases of MySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. and MariaDB are officially supported by excluding those with short lifespans or no guarantee of backward compatibility.
As a community, we frequently champion efforts to keep software and tools updated to their latest versions. This typically surfaces for users in the form of PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher upgrades, and for contributors with tools like Node.js and npm. Database software is equally important to site health but has historically received far less attention.
The release models followed by supported database types have changed quite a bit since the early days of WordPress. With that comes a need to update the project’s official policy for clarity. A clearer policy lends to a wider understanding of the expectations and requirements for maintaining WordPress sites.
But before getting into the changes being proposed, let’s define the various types of releases and examine current usage data before outlining a few things for discussion.
Note: If you’re already familiar with the release models of MariaDB and MySQL, you can skip the context directly to the proposal part of the post.
Supported Database Software
There are currently two types of database software officially supported for running WordPress: MySQL and MariaDB. While it’s true that SQLite powers Playground, standard installs of WordPress do not currently support SQLite without installing the feature plugin, which is being actively developed and tested.
Release Types
Both software projects have made several changes to the terminology used to reference releases, making it confusing and inconsistent. For the sake of clarity, here are the different terms associated with releases of MySQL and MariaDB.
Note: All asterisks (*) below indicate versions that have reached end of life (EOL) and are no longer supported upstream. Also, EOL does not always equal “unsupported by WordPress” (more on that later).
Long Term Support (LTS)
LTS versions are published by both projects. These are the most common versions found in the wild. They are actively supported for 5 years from the initial release. After initial release, data formats are not changed, no new functionality is introduced, and no features are removed.
While MariaDB aims to release a new LTS version annually, MySQL publishes a new LTS version every 2 years (starting with 8.4). The list of releases labelled as LTS to date is as follows:
| Version | Project | Initial Release | EOL Date |
|---|---|---|---|
| 8.4 | MySQL | April 30, 2024 | April 2032 |
| 8.0 | MySQL | April 19, 2018 | April 2026 |
| 11.8 | MariaDB | June 5, 2025 | June 2030 |
| 11.4 | MariaDB | November 22, 2024 | May 29, 2029 |
| 10.11 | MariaDB | February 16, 2023 | February 16, 2028 |
| 10.6 | MariaDB | July 6, 2021 | July 6, 2026 |
| 10.5* | MariaDB | June 24, 2020 | June 24, 2025 |
| 10.4* | MariaDB | June 18, 2019 | June 18, 2024 |
The following releases were treated as LTS versions, but were not explicitly labelled as such:
| Version | Project | Initial Release | EOL Date |
|---|---|---|---|
| 5.7* | MySQL | October 21, 2015 | October 21, 2023 |
| 5.6* | MySQL | February 5, 2013 | February 5, 2021 |
| 5.5* | MySQL | December 3, 2010 | December 3, 2018 |
| 5.1* | MySQL | November 14, 2008 | December 31, 2013 |
Innovation Releases
Though both projects use this classification, only the MySQL project actively uses it as described in this section (see the next section for how MariaDB currently uses the designation). Innovation releases aim to provide early access to new features and improvements without having to wait the full 2 years for the next MySQL LTS version to be published.
The following types of changes are included in new innovation releases:
- New features planned for the next LTS
- Security fixes
- Bug fixes
- New deprecations
- Removal of features
- Behavior changes.
These releases are Generally Available and are acceptable to use in production environments. They are published once per quarter (every 3-4 months). When the next innovation release is published, all support for the previous one is dropped, including security fixes. Because the lifespan of each innovation release is extremely short, consistent regular attention is required to remain supported and secure.
The following is a list of MySQL innovation releases.
| Version | Initial Release | EOL Date |
|---|---|---|
| 9.3 | April 15, 2024 | July 2025 |
| 9.2* | January 21, 2025 | April 15, 2025 |
| 9.1* | October 14, 2024 | January 21, 2025 |
| 9.0* | July 1, 2024 | October 15, 2024 |
| 8.3* | January 16, 2024 | July 1, 2024 |
| 8.2* | October 25, 2023 | January 16, 2024 |
| 8.1* | July 18, 2023 | October 25, 2023 |
MariaDB used this label for about 2 years. During that time, they also published a new innovation release every quarter. However, their innovation releases were supported for 1 year after initial GA release. These releases also differed from MySQL in that caution was advised when using these. As of the publish date of this post, all MariaDB innovation releases have reached EOL.
| Version | Initial Release | EOL Date |
|---|---|---|
| 11.2* | November 21, 2023 | November 21, 2024 |
| 11.1* | August 21, 2023 | August 21, 2024 |
| 11.0* | June 7, 2023 | June 6, 2024 |
| 10.10* | November 17, 2022 | November 14, 2023 |
| 10.9* | August 22, 2022 | August 22, 2023 |
| 10.8* | May 21, 2022 | May 20, 2023 |
| 10.7* | February 14, 2022 | February 9, 2023 |
Rolling GA (MariaDB only)
Though they’re similar in some ways, MariaDB now has replaced innovation releases with rolling GA releases. Rolling GA releases are published every quarter (3-4 months) and receive no patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. versions (the GA release is final). All support for the previous rolling release is dropped once a new one is published.
The term innovation release is still used but now refers to the preview (X.Y.0) and RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). (X.Y.1) pre-release versions for each rolling release. Rolling GA releases are intended for production use, but the innovation releases are not.
| Rolling Release Versions | Initial Release | EOL Date |
|---|---|---|
12.1 (currently in preview innovation release) | TBD | |
12.0 (currently RC innovation release) | TBD | |
| 11.7* | February 13, 2025 | May 12, 2025 |
| 11.6* | November 22, 2024 | February 13, 2025 |
| 11.5* | August 15, 2024 | November 21, 2024 |
| 11.3* | February 19, 2024 | May 16, 2024 |
Major Release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.
MySQL refers to major versions in the same way as WordPress (X.(Y+1)).
For MariaDB, this term has meant different things during different timeframes.
| 10.3 and earlier | X.(Y+1) | Every new release |
| 10.4-11.2 | X.(Y+1) | Each version was considered major because of binary incompatibility and the addition of new features. LTS or short-term become more common descriptors as they indicate length of support (similar to WordPress). |
Current day *(>= 11.3) | (X+1).0 | Only when the first number changes (similar to PHP). |
While the LTS designation did not exist yet, versions 10.3 and earlier were treated in a similar way.
- Supported for 3-5 years (sometimes longer)
- Bug fixes and security updates were provided
- New features were sometimes included in minor (
X.Y.(Z+1)) releases, but compatibility was always maintained.
All MariaDB major releases <= 10.3 have reached EOL. They’re listed below for completeness:
MariaDB Major Versions <= 10.3 | Initial Release | EOL Date |
|---|---|---|
| 10.3* | May 25, 2018 | May 25, 2023 |
| 10.2* | May 23, 2017 | May 23, 2022 |
| 10.1* | October 17, 2015 | October 17, 2020 |
| 10.0* | March 31, 2014 | March 31, 2019 |
| 5.5* | April 11, 2012 | April 11, 2020 |
| 5.3* | February 29, 2012 | March 1, 2017 |
| 5.2* | November 10, 2010 | November 10, 2015 |
| 5.1* | February 1, 2010 | February 1, 2015 |
While some online resources show the LTS label next to these versions, they were never officially labelled as such.
Short-term (MariaDB Only)
This term was eventually replaced by innovation release. This applied to MariaDB 10.4 in addition to the MariaDB versions listed above under Innovation Releases. As of the publish date for this post, all short-term releases have reached EOL.
Current Database Usage Data
Here is the usage data according to the WordPress.org Stats page as of June 18, 2025 summarized in a few different ways:
By Software
| Version | Usage |
|---|---|
| MariaDB – all versions | 52.8% |
| MySQL – all versions | 47.2% |
By Version Type
| Release Type | Usage |
|---|---|
| MariaDB LTS (includes old major releases without LTS official designation) | 51.17% |
| MySQL LTS (includes old major releases without LTS designation) | 46.74% |
| MariaDB Innovation/Short-term/Rolling Releases | 1.52% |
| MySQL Innovation Releases | 0.07% |
| Other | 0.5% |
By Support Status
| Support Status | Usage |
|---|---|
| EOL versions (MariaDB) | 11.43% |
| EOL versions (MySQL) | 26.01% |
| Supported (MariaDB) | 41.56% |
| Supported (MySQL) | 21.05% |
Observations
There are a few interesting things that stand out from the usage data.
- As of March 2025, MariaDB now powers more WordPress sites than MySQL. This is particularly interesting because as of January 2024, the split was ~63%/37% in favor of MySQL. Increases in licensing costs and changes to widely used distributions during 2023 and 2024 are likely the considerable drivers of this surge.
- Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates.
- The highest adoption of any innovation/short-term/rolling release was MariaDB 11.3, which reached 0.15%.
- No other innovation/short-term/rolling releases have surpassed more than 0.10% adoption at any given point in time.
Current State of Database Support in WordPress
Despite MySQL and MariaDB having different release models that drop support in different ways in non-sequential order, WordPress has a very binary support policy. As of the publish date of this post, the support policy is as follows:
- Recommended: MySQL >= 8.0 OR MariaDB >= 10.6
- Required: MySQL OR MariaDB >= 5.5.5
A few notes:
- MariaDB 10.5 reached EOL on June 24th. The recommended version was updated to >= 10.6 on June 18, 2025 (see #60319 and #meta-8013).
- The minimum required version was last bumped in late 2023 (see [57173]).
The policy as currently stated is lacking any guidance around which types of releases are supported. As demonstrated above, this is complicated and convoluted. The policy should be expanded a bit to cover release types and not just versions.
Proposal: Clarify Supported Release Types
While described as production-grade, innovation releases have several shortcomings when considering the majority of WordPress sites.
- Features and changes included in innovation/rolling releases are considered stable, but they can be modified or even removed entirely in future releases. No functionality can be considered supported until included in an LTS release.
- Their ephemeral nature makes it very difficult to ensure compatibility with WordPress when released. Depending on how release timelines overlap, there could be 2 (or more) innovation/rolling versions published in between major WordPress releases.
- Their extremely short lifespans could potentially leave large numbers of sites running insecure versions.
- Updating database software is often tied to factors out of the site owner’s control (waiting for server distributions to be updated and made available through your hosting, platform compatibility limitations, compliance/licensing requirements, etc.).
- For both projects, updating these release types is complicated. Updates must be applied sequentially. For example, upgrading from 9.1 to 9.3 is not supported (
9.1must first be updated to9.2before updating to9.3). This is not required when upgrading to the next LTS. - Over the last two years, these release types have not shown significant usage, even when combining the numbers across database types.
- Because the changes in these releases are not guaranteed to be backwards compatible, committing to full compatibility with these releases is not a good use of contributor time and could result in making code harder to maintain.
Changes to the Database Recommendations
This proposal is suggesting that the recommendations for running WordPress be updated as follows:
- No change: The oldest LTS versions actively supported upstream should continue being used as the recommended minimums.
- Add to the Requirements page, Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress./Hosting/Support/Other? Handbooks: Innovation and rolling GA releases are explicitly not recommended for production sites.
- Add to the Hosting Handbook: Hosting companies are explicitly advised not to use Innovation and Rolling GA releases as the default for new sites.
The WordPress PHPUnit testing workflow currently runs the test suite using the most recent MySQL innovation and MariaDB rolling GA releases. This practice helps to make contributors aware of potential incompatibilities and breaking changes so they can be addressed prior to the next LTS version. This practice will continue.
Because of this, it’s reasonable to expect WordPress to have very few (if any) issues when running these releases. However, this is not guaranteed as contributors must weigh the benefits of making changes for the sake of compatibility with the non-zero chance that the feature is changed or removed before the next LTS release.
Because innovation and rolling GA releases are never supported, only LTS versions are eligible as new minimums when considering changes to the minimum required versions of MariaDB/MySQL to run WordPress in the future.
In summary, someone is free to run innovation and rolling GA releases, but they do so at their own risk.
Other Considerations
As a part of this, ways to further educate and empower the user should also be explored.
- Should
servehappybe expanded to display a dashboard notice to the user when their site is running an outdated or unsupported version of MariaDB/MySQL (see #63634)? - Can there be additional context for the database checks in Site Health to detect innovation/rolling GA releases explaining why they should consider using an LTS version instead?
- Are there ways to enhance WP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ to properly advise about these risky release types?
- Are any meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. changes required to better inform the site that these release types are not explicitly supported?
- Do the auto-update related classes require any changes?
Working Together
Reliable and supported database software is foundational to the performance, security, and longevity of WordPress a site. Historically, efforts to promote upgrades among hosts and site owners have been limited and inconsistently prioritized. Clarifying the types of database releases that WordPress supports and is compatible with marks an important first step. It enables contributors, hosts, and site owners to move toward more secure and sustainable versions of MariaDB and MySQL.
Props @johnbillion, @flixos90, @l1nuxjedi, and @annezazu for peer review.
