Who is responsible for maintaining the MariaDB version you run?

The MariaDB Foundation’s 31 October reminder concerns an earlier lifecycle change: Community 10.6 maintenance ended on 6 July 2026. Its August notice identifies 10.6.28, released on 13 August, as the final Community release. This is a current maintenance decision, not a new November shutdown. (MariaDB Foundation, MariaDB Foundation)

Record the package, the owner and the promise

A version number is one entry in a maintenance record. It does not identify the organisation responsible for the package you run, the support arrangement you bought or the person who can schedule a database change. Start with those distinctions before choosing a replacement branch.

Keep production, staging and any reporting replica as separate rows. If the provider cannot identify the build or coverage, record that as an unresolved dependency. A screenshot of a hosting sales page should not fill the gap: it describes an offer, not necessarily the database serving your application.

The Foundation’s policy distinguishes Community, Enterprise and Extended maintenance, and binary availability from source-fix periods. MariaDB Server’s GPLv2 licensing does not itself provide a commercial support agreement. Ask which published policy and contracted service apply to your particular package. (MariaDB Foundation)

Compatibility and maintenance need different evidence

WordPress currently recommends MariaDB 10.11 or later, or MySQL 8.0 or later. That application-level recommendation does not tell you what your host runs or whether a particular theme, extension and integration have been tested on a proposed target. (WordPress.org)

Consider a hypothetical agency maintaining a client’s WordPress store. The agency has application access; the host controls the database. The useful next step is a joint decision record: the host supplies package and maintenance evidence, while the agency lists the store journeys and integrations that must survive the change. Neither party can substitute its own checklist for the other’s responsibility.

For a proposed migration, define acceptance around the actual application. A representative check might cover signing in, editing a product, placing an authorised test order and reconciling the resulting records. Include a path that exercises a relevant extension or scheduled job. These are suggested checks, not tests performed by KIURO or proof that every WordPress installation supports a particular target.

Ask for a transition you can review

• Which exact database package is covered, by whom, and until when?
• What target branch and build are proposed, and why do they fit the application and maintenance horizon?
• Which application checks will run in a representative isolated environment, and who accepts their results?
• What recovery evidence and rollback decision are required before the production change?
• Who owns the maintenance window, communication and follow-up observations?

Keep the response attached to the deployment record. If the provider offers additional maintenance instead of an immediate migration, ask what it covers and what remains the application team’s work. A commercial label alone is insufficient evidence; equally, an upstream Community EOL does not tell you the terms of every separately maintained distribution.

Budget for the decision as well as the change

No hosting, migration or support price has been verified for this guide. A useful estimate should separate provider-plan changes, compatibility work, the recovery rehearsal, the change window and ongoing maintenance. Include the people needed to approve business journeys; their availability can be a dependency even when the technical work is ready.

The next deliverable should be a short maintenance-and-transition record with named owners, evidence and open questions. If you need an ongoing operating arrangement, the scope of technical care and optimisation can be discussed against that record. The choice of a destination version should follow the evidence, not simply the largest number on a release list.