Как вы спланируете выкатку изменения, затрагивающего и код, и схему базы, чтобы её можно было безопасно откатить?

Принцип. Во время выкатки и отката живут обе версии кода, поэтому каждый шаг должен быть совместим с текущей и предыдущей версией.

План:

1. Расширение схемы — отдельным релизом: новые таблицы и nullable-колонки, индексы CONCURRENTLY. Старый код их не замечает.
2. Код под флагом — пишет и в старое, и в новое; новое поведение выключено. Выкатка постепенная (canary), метрики по версии.
3. Бэкфилл — порциями, с контролем нагрузки и отставания реплик.
4. Включение флагом — постепенно, по процентам; быстрое выключение при проблемах.
5. Переключение чтения на новое.
6. Сужение — удаление старого кода, затем, через период наблюдения, удаление старых колонок. Это необратимо — поэтому последним.

Откат: на шагах 1–5 откат кода безопасен — старые данные на месте. После удаления данных остаётся только исправление вперёд (roll-forward). Поэтому необратимые шаги отделяют по времени и делают, когда уверены.

Проверка: прогон миграции на копии продовых данных (время, блокировки), таймауты на миграции (lock_timeout), отрепетированный откат, мониторинг ошибок и задержки в разрезе версии.