According to https://wikitech.wikimedia.org/wiki/Schema_changes/Coordination_proposal all changes to existing database tables require DBA approval, which should be planned as taking up to 2 weeks. While that is reasonable for many MediaWiki tables, which often contain millions of rows or get hundreds of reads per second, development is disproportionately concentrated at small tables, since most actively developed features are new and still in beta feature status, and not enabled by many users, which means they only get a fraction of the normal Wikimedia traffic levels. At the same time, these are the tables where velocity of change matters the most; anything that cannot be done in a single sprint will hold the whole team back. There are also non-beta examples of tables where a schema change has a negligible impact: functionality that's limited to advanced rights holders and thus rarely used, extensions which live on a single special page, or are only deployed on a small sister project.

Using the standard schema change permission workflow for such tables is bad for everyone: it keeps the developers from moving fast, it delays the feature providing value to the users, it wastes the DBAs' time on trivial changes that do not require their expertise. Eventually, it might result in developers "routing around" the bottleneck, such as storing JSON blobs in a table because that way a "schema change" can be done with a simple UPDATE command. (The example is not fictional.)

There should be some kind if minimum criteria (along the lines of "at least X rows or Y writes per minute or Z reads per minute") under which schema changes can be done on a self-service basis.