Как вы изменяли структуру базы данных и создавали или изменяли таблицы

Что проверяют

Меняли ли вы схему живой базы и понимаете ли, чем это опасно под нагрузкой. Интересует не синтаксис CREATE TABLE, а процесс: версии, выкатка без простоя, откат. Следом часто спрашивают, как переименовать колонку в таблице на десятки миллионов строк.

Как отвечать

Расскажите о своём проекте по шагам:

• инструмент: Flyway или Liquibase, запуск при старте Spring Boot или шагом пайплайна. Файлы вида V12__add_status.sql, применённую миграцию не редактируют: Flyway сверяет контрольные суммы;
• схемой управляют миграции: в проде spring.jpa.hibernate.ddl-auto=validate или none;
• expand/contract: добавить колонку, выкатить код, который пишет в обе, заполнить старые строки пачками, переключить чтение и только в следующем релизе удалить старую. Так две версии приложения переживают rolling-выкатку на одной схеме;
• блокировки в PostgreSQL: ADD COLUMN с константным DEFAULT мгновенный с версии 11. Индекс на большой таблице строят через CREATE INDEX CONCURRENTLY, вне транзакции, в Liquibase это changeset с runInTransaction="false". NOT NULL добавляют через CHECK ... NOT VALID и VALIDATE CONSTRAINT, без эксклюзивной блокировки на весь проход;
• lock_timeout: миграция, ждущая блокировку, выстраивает за собой все запросы к таблице, поэтому ей ставят короткий таймаут и повторяют;
• проверка: прогон на копии данных или в Testcontainers, замер времени.

Цифры приводите свои: размер таблицы, сколько шла миграция, был ли простой. Если опыт только на пет-проекте, скажите прямо и объясните, как сделали бы на большой таблице.

Где спотыкаются

Оставляют ddl-auto=update в проде. Hibernate не удаляет и не переименовывает колонки, истории нет, схемы стендов расходятся.

Правят применённую миграцию. Везде, где она прошла, приложение перестаёт стартовать из-за контрольной суммы.

Переименовывают или удаляют колонку одним шагом. Во время rolling-выкатки старые экземпляры обращаются к прежнему имени и сыплют ошибками.