Thank you for your thoughts, Travis!

As you say, there's unlikely to be any compatibility issues between Trove and the replica databases; in any case, the replicas are due for an upgrade soon.

We don't have any plans to actively shutdown older Trove databses. If a situation does arise in the future where that's needed (e.g. a major security concern) I will feel better knowing that alternatives have been available for as long as possible.

Running offsite backups is fine (and mostly upside from our perspective) unless you're using a ton of bandwidth and/or your database is extremely large. You shouldn't feel any rush to upgrade your existing DB, although I'm certainly interested in whether or not it is easy for you to restore/import one of your backups onto the new engine.

I hope that's all of your concerns, let me know if I missed anything.

-Andrew

On 3/27/26 8:46 AM, Travis Briggs via Cloud wrote:

Hi Andrew,

My main concern is that the enwiki_p replica at enwiki.analytics.db.svc.eqiad.wmflabs is currently on 10.11.13 and I'm not aware of plans to upgrade it. Tools like ours (mwcurator/WP1) connect to both the wiki replica and our Trove, and I'm wondering what the implications of running on different versions would be.

Answering my own questions in public:

1. My general expectation is that newer versions of database software

are backwards compatible from an API perspective, and that differences are adding features and optimizations. 2) Keeping in mind the above, I believe both the official MariaDB connector Python library, as well as pymysql (which is what we actually use) support both versions. 3) Having multiple versions for dev environment is not necessary simply because our databases in dev are containerized. And even then, it would only be a concern for the most paranoid of development postures, which we don't take.

The other thing I worry about is that 10.5 is EOL, and 10.6 is only supported until July 2026, like you mentioned. In my experience, EOL is a phrase that makes SREs jumpy. I know you are planning on continuing to operate existing versions /for now/ but I wonder if there is a forced migration somewhere on the horizon (see what I did there?). I'm thinking of the debian upgrades which were fairly painful for us (though those I understand as being more critical).

Finally, as a data point for your team, WP1 performs nightly external backups of our Trove database external to Horizon. I don't know if I should be mentioning that because we might get in trouble for resource usage 😅. We have successfully run restore operations in the form of yearly exercises.

Thanks as always, -Travis

On Fri, Mar 27, 2026 at 6:20 AM Andrew Bogott via Cloud-announce via Cloud cloud@lists.wikimedia.org wrote:

tl;dr: new trove database versions are coming! Existing trove db
servers will continue to run as before. Please provide feedback
about the specifics.

--

Sometime in the next few weeks I'd like to make a few updates to
the databases supported on cloud-vps. Unless you have your own
private database, toolforge users can ignore this email. If you
ever visit the 'databases' tab in Horizon please read on!

Right now we support the following database engines:

mariadb10.5.10 (21 instances)
mysql5.7.29(4 instances)
postgresql 12.7 (13 instances)

I propose to deprecate all three of those engines, and replace
them with:

mariadb12.2.2
postgres18

Here's how that would look, from a user standpoint:

1) **Any existing database instances will continue to run and
operatein Horizonas before.**

2) It will no longer be possible to create new database instances
with the deprecated engines.

3) It will no longer be possible to restore backups of databases
using the old engine without admin intervention -- if we do this,
I will be on hand to do manual restores if necessary. This
restriction is bound up with #2 above; either both rules stay or
both rules go.[0]

4) There will be no automatic or in-place upgrade path provided
from old version to new version. Any upgrades, if needed, will
have to be performed 'by hand' with something like an
outside-of-openstack dump and restore. This pains me but I've
spent some time testing and the internal storage formats are too
different for a smooth transition.

5) It will no longer be possible to create new mysql databases.
Mysql is not very popular, and as far as I know only provides a
functional subset of mariadb.

I'm making a lot of assumptions about you, the users, in this
proposal, so please speak up if (for example) you perform frequent
backup restores, or have a use case that requires mysql. You can
respond to this email, or follow up on the associated phab task[1].

If this email provokes only silence or agreement, then I will make
these changes on or near April 20.

[0] Currently only a total of 9 trove backups exist (and only 4 in
the last year), so I suspect no one is really relying on this
service on the regular.
[1] https://phabricator.wikimedia.org/T420737




_______________________________________________
Cloud-announce mailing list -- cloud-announce@lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.org/
_______________________________________________
Cloud mailing list -- cloud@lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/

---

Cloud mailing list --cloud@lists.wikimedia.org List information:https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/