Let me clarify the reasoning for the idea: We realized that some schema changes (which used to be scheduled like other deployments) no longer take 1 hour (they can take 1 month, running continuously like https://phabricator.wikimedia.org/T139090 , because it affects 3 of our largest tables). Also, they no longer requires read-only mode or affect code in anyway (unless they are a prerequisite). On the other side, a schema change, combined with high read or write load from long-running maintenance jobs, like those of the updateCollation script, or any other (those where just an example), could potentially make lagging a worse problem: a single transaction has to store pending changes during its lifetime, or long-running reads can block and create pileups due to metadata locking. We want to avoid those, which certainly caused infrastructure issues in the past. So, in summary, regular deployments are exclusive from each others. Long-running maintenance work could affect each other. This is a way for me (and others) to have visibility of those potential negative interactions, and make sure we can coordinate: "You are doing work on enwiki? No problem, we will just run this task for commons". "you need to do an emergency data recovery? I will wait to do this other task that can wait". Even if only DBAs use it, it is already useful to not perform incompatible changes at the same time. But it will be even more useful if everybody uses it! On Thu, Sep 22, 2016 at 4:27 PM, Alex Monk &lt;amonk(a)wikimedia.org&gt; wrote: -- Jaime Crespo <http://wikimedia.org>