For me this is a duplicate of T104459, or at most, a subtask.

Short term, what I would do is maintain a tables.sql on "operations side", meaning a version controlled fork of tables.sql with the current progress so it is easier to track than looking at all the patches on Schema-change-in-production.

Most of the tools you mention are unsuitable for WMF hosts because they cannot handle the hundred of thousands of objects of s3 or the large, unindexed (no primary keys) of enwiki, commons etc. Solving T17441 would be in most cases a blocker.

Subtask maybe, yeah. I wanted to do something for non WMF wikis, as we know how of skew Wikimedia wikis get, due to missing patches.

So people can look, and find any missing patches/changes, and hopefully report them back to us to remediate....

Sorry I missunderstood you- because you added us WMF DBA s and used WMF as a context, I thought you wanted a WMF-only solution, not a mediawiki one. Now I understand what you mean.

Removing the DBA tag and subscribing myself instead. Once there are specific actions for DBA please re-add us and/or @mention me.

@Ladsgroup does your recent work perhaps address this?

Yes. Since this was created, we found and fixed lots of schema drifts, even on s3 T260111: All sorts of random drifts in wikis in s3 and even ran it on localhost with update.php run to make sure update from an old version works fine and found an issue that got fixed. But it's a python script and not a mw maintenance script. I have mixed feelings about whether we should port it to mw core or not. It actually makes more sense these days with abstract schema but back then it made more sense to have it on python (because you basically needed to write a sql parser for it).

Pros of mw script:

• It's available everywhere out of box
• It can take advantage of mediawiki DBAL to check if a table has index/column/datatype/etc.

Pros of the python version:

• It's already implemented, we don't need to do much.
• It has been working and tested several times
• You can easily adapt it to check extensions, etc.
• It doesn't need to satisfy high standards of core (that's technically not a pro tbh but I'm lazy)
• I have been cleaning all sorts of unused and broken mw scripts that have been sitting around for decades, I think there should be a strong reason to add more to it as it's likely will stay there forever.

@Reedy Does the above satisfy your original requirement (and is the original requirement from 2017 still valid)?