Proposal: Clarifying Core’s Database Support Policy

WordPress wants to draw a clearer line on database “support” — and it’s mostly about boring, high-impact defaults

If you’ve ever tried to answer “is WordPress *supposed* to run on this MySQL/MariaDB version?” you’ve probably ended up with a shrug and a link to the Requirements page.

A new proposal on Make/Core tries to fix that by adding a missing dimension to WordPress’ database guidance: not just *which version numbers* are OK, but *which release types* WordPress considers a sane default in production.

The proposal (worth reading in full) is here:

Proposal: Clarifying Core’s Database Support Policy

A concrete scenario: the “my host upgraded something” surprise

Picture an agency that maintains a few dozen WordPress sites on managed hosting. Everything is stable. Then a platform update rolls through and suddenly a chunk of sites are running a database version that’s technically “GA,” but lives on a short, quarterly cadence (or has behavior changes that aren’t guaranteed to be backwards compatible).

Nothing is *immediately* broken — but now you’re in a weird place:

• You can’t tell clients “this is a supported configuration” with any confidence.
• You can’t assume upstream security support will still exist in a few months unless the host keeps upgrading on schedule.
• Even if WordPress core tests against these releases, it’s hard to justify spending contributor time chasing edge-case compatibility for versions that may change or disappear before the next long-term support line ships.

That’s the kind of ambiguity this proposal is aiming at.

What’s actually being proposed

The headline is simple: WordPress should clarify that LTS releases of MySQL and MariaDB are the officially supported baseline — and that short-lived “innovation” (MySQL) and “rolling GA” (MariaDB) releases are not recommended for production defaults.

Some context from the post makes the motivation pretty stark: as of mid‑2025, over 37% of WordPress sites were on database versions that had already reached upstream end-of-life, meaning no ongoing maintenance or security fixes.

Rather than only bumping version numbers occasionally, the proposal suggests WordPress should communicate (more explicitly) that:

• The *recommended* baseline should stay anchored to the oldest upstream-supported LTS lines (today that’s generally MySQL 8.0+ and MariaDB 10.6+, per the Requirements page: https://wordpress.org/about/requirements/).
• Innovation/rolling releases may be fine for advanced operators, but they’re “at your own risk” for typical site owners.
• Hosts should avoid setting these fast-moving lines as the default for new WordPress installs.

The nuance: WordPress will still test the fast-moving releases

One detail I like here is the honesty about tradeoffs.

The post notes that WordPress’ PHPUnit test matrix already runs against the latest MySQL innovation release and MariaDB rolling GA release. That practice would continue — not because these releases are “supported,” but because it helps catch breaking changes early enough to respond before they land in the next LTS.

In other words: the project can *pay attention* to the frontier without telling the whole ecosystem to live on it.

Risks and open questions (where it gets real)

Even with clearer policy language, the hard part is changing behavior. The proposal points to a few pragmatic follow-ups that feel more impactful than a paragraph on a handbook page:

• More proactive user education (for example, expanding Serve Happy to warn when your database is EOL: https://core.trac.wordpress.org/ticket/63634).
• Better Site Health messaging that distinguishes “you’re on a weird release type” from “you’re on an old version.”
• Potential WP-CLI improvements so it can advise about risky release lines in a way that’s actually actionable.

If WordPress is serious about shrinking the long tail of insecure infrastructure, these “how do users find out?” touchpoints are where the policy turns into outcomes.

What builders and site owners should do now

If you operate WordPress sites (or build products that run on them), this is the practical takeaway:

• Prefer LTS database lines unless you have a very specific reason not to.
• If you’re on a host you don’t fully control, ask what database release track you’re on — not just the version number.
• For plugin and hosting teams, assume that “recommended” is going to keep meaning “oldest upstream-supported LTS,” and plan compatibility/testing around those lines first.

It’s not a flashy proposal. But it’s the kind of infrastructure clarity that makes everything else — performance, security, even upgrade messaging — easier to reason about 🔒