[Policy] How to select the minimum required database versions

Thanks @daffie, avoiding bottle necks is important to allow progress, as also discussed in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions.

@daffie by latest version do you mean 'MySQL 8' as opposed to 5.7, or 'MySQL 8.0.34' as opposed to 'MySQL 8.0.25'?

The complication I think is that sometimes latest means 'released two years ago' and sometimes it means 'released a month ago'. Also the release cycles of the three core-supported databases are very different. With MySQL there's also the MySQL vs. MariaDB schedules and versioning too.

It looks like PostgreSQL does major releases approximately every year

https://www.postgresql.org/about/news/postgresql-15-released-2526/
https://www.postgresql.org/about/news/postgresql-14-released-2318/
https://www.postgresql.org/about/news/postgresql-13-released-2077/

I dread to say it, but we might need different approaches for all three databases, for example we generally assume that people running PostgreSQL or sqlite have specific use cases or requirements, so requiring the very latest versions of those should be easy to do without causing too many problems. For MySQL we want people to be able to run on mass hosting where possible, so might need to be a bit more careful. The main thing for core is being able to adopt features that all three databases have in common, or things that bring them into line with one another that we've previously implemented workarounds for or have outstanding bug reports about.

I am curious if there are any relevant statistics for this?

Most Drupal sites use containers and can run with any database version that is required.

Re #4 I agree that MySQL is surely our primary database engine and we probably want to be a bit more conservative there, but it is likely that Postgres and SQLite can be closer to the bleeding edge.

Since we moved database drivers to modules, it would be good to get some update.module stats from the DA so we can see exactly how popular (or not) Postgres and SQLite are.

Things have moved on a bit since I last posted here:

I found PostgreSQL's versioning page which I'm not sure I'd seen previously, and that confirms there's an official (but not exact) yearly release cycle and the actual releases always seem to be in September or October.

https://www.postgresql.org/support/versioning/

Given PostgreSQL 16 was released in September 2023, then I think it would make complete sense for us to require that, and we can expect there won't be a PostgreSQL 17 until Autumn 2024. So for a policy wording, something like 'the most recent PostgreSQL major version that is available prior to the first beta window for a Drupal major version'. This is very similar to what we're doing with PHP too.

However, there is no corollary for sqlite https://www.sqlite.org/changes.html they seem to do a minor release every few months on no particular schedule. So our policy will probably have to be 'pick an sqlite minor version based on feature set and availability' which is what it is now by default.

For MySQL, they seem to have announced a formal release schedule too: https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-lon... This suggests an LTS every two years, with 8.0 as the current one and 8.4 as the next one. It does not look like 8.4 will be available before Drupal 11.0.0-beta1 though.

I don't think we can not support any MySQL LTS release (like requiring MySQL 8.1 now before 8.4 is available), but maybe once MySQL 8.4 is out, we could require MySQL 8.1 or something if there were specific features we want, on the basis that mass hosting is likely to enable MySQL 8.4 soon as the new LTS. But probably it's simplest to say 'the MySQL LTS available before the first major beta window' which will be MySQL 8.0.

MariaDB also has formalized their schedule a bit - they have LTS and one-year support minors, i.e. 10.6 and 10.11 are supported for five years, 10.7/8/9/10 supported for just one year. 11.x releases are happening but there is no LTS minor on that branch yet. https://mariadb.org/download/?t=mariadb&p=mariadb&r=10.11.6&os=Linux&cpu...

I mostly agree with #7, but with a few tweaks...

For MySQL, I think we should be the most conservative, which means I would prefer instead of:

'the MySQL LTS available before the first major beta window'

something more like 'the MySQL LTS that's been in an Ubuntu LTS for at least a year before the expected Drupal major release date'.
Given the alignment of Drupal's cycle with Ubuntu's cycle, in practice I think that'll often be the same thing, but in cases where MySQL releases an LTS after Ubuntu's feature freeze, or if Drupal changes its cycle to be less aligned with Ubuntu's, then my version is a bit more conservative.

For PostgreSQL:

the most recent PostgreSQL major version that is available prior to the first beta window for a Drupal major version

Except we want to set our requirements 3 months before beta. But given PostgreSQL's schedule of Sep/Oct, I think we could change this to the most recent PostgreSQL major version that is available 6 months before the expected Drupal major release date without that making a difference to the version that that corresponds to.

For MariaDB, I think we should get Pantheon's input into what their constraints are around adopting MariaDB versions.

For SQLite, I think we could potentially be as aggressive as "the version that's in the latest Ubuntu LTS before Drupal's beta", or as conservative as "the version that's in the latest Ubuntu LTS, Debian, and MacOS before Drupal's beta", or in between the two (e.g., Ubuntu and MacOS but not Debian). I think for any given Drupal major version we should base what we choose within that range on how important are the features in the newer SQLite release. For Drupal 11, SQLite 3.45 has jsonb which I think is important, so if that makes it into Ubuntu 24.04, I'd support that minimum even if it means early testers/users on Debian and Mac need to manually upgrade their sqlite or install a contrib driver. However, if Ubuntu's latest ends up being 3.44, then I don't think there's anything between 3.40 and 3.44 that's useful (I don't think json5 in db insert/update queries is useful to Drupal), so I'd go down to 3.40, or even to 3.39 in order to pick up the 2nd latest MacOS. Basically, where it costs us nothing to make things a bit easier for more people, I think we should do that where we can, but where core development/maintenance gets a tangible benefit from a higher minimum, we should choose that higher minimum within reason.

Started working on proposed text and added that to the issue summary.

I should have set this to needs review to get feedback on the proposal.

MariaDB 10.6 will be out of community support in mid-2026, e.g. roughly when we're expecting to release Drupal 11.

Since 10.6 there are three LTS version:

10.11 - community support until Feb 2028
11.4 - community support until May 2029
11.8 - community support until June 2028 (yes this is sooner than 11.4 is out of support). 11.8 was released 4th June 2025 so it's quite new.

(From https://endoflife.date/mariadb)

If we follow #8, then that points to requiring MariaDb 10.11, since that's what's included in Ubuntu 24.04

For MySQL itself, it's a bit more vague: https://launchpad.net/ubuntu/noble/+package/mysql-server but de-facto you still get 8.0 it looks like. However I wonder if they're going to switch that mid-release to 8.4 (supported until 2029 according to https://endoflife.date/mysql) as 8.0 goes EOL). So maybe it would be fine to require 8.4 according to #8 if ubuntu installs get updated anyway.

MariaDB 12 (rolling release) is out https://mariadb.com/docs/release-notes/community-server/release-notes-ma...

I think it makes sense to wait for 12.1.2 to add CI image

Postgresql 18 will be released in September

https://www.postgresql.org/developer/roadmap/

For MySQL itself, it's a bit more vague: https://launchpad.net/ubuntu/noble/+package/mysql-server but de-facto you still get 8.0 it looks like. However I wonder if they're going to switch that mid-release to 8.4 (supported until 2029 according to https://endoflife.date/mysql) as 8.0 goes EOL). So maybe it would be fine to require 8.4 according to #8 if ubuntu installs get updated anyway.

I don't see what's vague in that link. It looks clear cut that Ubuntu 24.04 is on MySQL 8.0. I don't think there's any precedent for Ubuntu to raise the minor version of MySQL (or any other significant package) within an LTS branch that has already been released. Based on all of their track record, I expect Ubuntu to security patch MySQL 8.0 for as long as 24.04 is supported (till 2029 minimum and beyond that for extended support). I think #8 would clearly dictate having Drupal 12 require MySQL 8.0, not 8.4. I don't know if we have consensus on #8, but I'm still in favor of that. Most people are not going to upgrade from Ubuntu 24.04 to 26.04 within the first year of Drupal 12 being out, and while it's true that those people can remain on Drupal 11, I don't think we gain enough from raising the MySQL minimum to 8.4 to be worth the tradeoff in holding back Ubuntu 24.04 users from upgrading to Drupal 12.

From that link:

This is an empty package that depends on the current "best" version of
mysql-server (currently mysql-server-8.0), as determined by the MySQL
maintainers. Install this package if in doubt about which MySQL
version you need. That will install the version recommended by the
package maintainers.

So do you think that means that they update this to the 'best' version of MySQL each Ubuntu release, rather than updating it within an Ubuntu release? If so that's probably right but it's not how I read it the first time.

Update proposed language to be like the existing policy for setting PHP requirements.

So if we go with @effulgentsia's suggestions, except for sqlite where we already require 3.45 for Drupal 11. sqlite 3.45 turned out to be tricky for ddev the first month or so after 11.0.0's release due to upstream containers not being available iirc, they worked around it quite quickly, but another reason to be slightly circumspect here.

Drupal 11 status quo:

MariaDB 10.6+
MySQL/Percona 8.0+
Drupal 11 requires SQLite 3.45 or higher.

Drupal 12:

MariaDb 10.11
MySQL 8.0
sqlite 3.45

So de-facto, we'd raise the minimum version of MariaDb, which has a very clear EOL/LTS schedule now, and leave things the same for MySQL and sqlite.

Assuming Ubuntu 26 raises the MySQL minimum version, this would mean that MySQL gets a higher minimum in Drupal 12 after two major releases of us not changing our minimum - might be worth announcing that longer in advance.

Added more to the proposal resolution based on recent discussion. Specially, incorporating the use of Ubuntu.

Mysql 9.6 is out so in 3 months 9.7 LTS will be released, meantime test for mysql 9.5 pass but I used to update config both for passwords and default encoding, also disabled MyISAM which saved ~500MB of RAM

I checked with the release managers, catch and longwave are fine with this, so removing tag.

Just need Needs framework manager review to complete this.

The proposed text looks considered and appropriate to me, removing FM tag - thanks for working on this