На первом шаге деплоим скрипты миграции и код, который читает со старой схемы, но пишет и в старую, и новую. Потом перегоняем данные из старой схемы в новую ("пересчитываем поля"). На втором шаге льем код, который читает из новой версии схемы.
Еще знаю кейсы когда деплоят новую версию которая смотрит в две таблицы и делает update data on fetch. Условно: делаем запрос в новый источник данных, если там ничего нет - то забираем из старого, а после всех трансформаций и действий сохраняем в новый
Сейчас можно уже взять отдельной тулзой https://github.com/pressly/goose и прикрутить его к любому проекту. Это если твой фреймворк не умеет сам миграций
У наемных работников недостаточно мотивации защищать чужие секреты. Они то просто найдут нового работодателя, зачем рисковать получить люлей. И это правильно, истории вида "продавщица обезвредила грабителей получив 10 ножевых" никак иначе, чем "слабоумие и отвага" назвать язык не поворачивается. Так что сравнение некорректно.
У нас нет настолько больших таблиц, чтобы это было проблемой, а индексы вообще добавляются очень редко. Ну и чисто теоретически MySQL с версии 5.6 умеет в online DDL без блокирования таблиц.