Что такое миграция схемы и почему она заменяет ad-hoc DDL

Отто хочет добавить колонку phone в таблицу users. Он открывает psql и запускает ALTER TABLE users ADD COLUMN phone TEXT. Три месяца спустя приходит новый инженер, клонирует репозиторий, получает ошибки — в его базе нет колонки phone. Никто не знает, что нужно изменить. Схема разошлась.

Проблема с ad-hoc DDL

Запуск ALTER TABLE напрямую в psql работает один раз, на одной машине, для одного инженера. Как только появляется вторая среда — стейджинг, CI, ноутбук коллеги — схема молча расходится. Никто не отслеживает, что изменилось и когда. Возможность воспроизвести всё заново теряется.

Файл миграции кодирует изменение как именованный, упорядоченный артефакт:

-- migrations/20260514_add_user_phone.sql
ALTER TABLE users ADD COLUMN phone TEXT;

Инструмент миграции записывает, какие файлы были применены, в таблицу schema_migrations. Новый инженер, запустив prisma migrate dev или flyway migrate, получает все ожидающие миграции в правильном порядке. База приходит в одно и то же известное состояние на каждой машине.

Миграции версионируются как коммиты

Порядок деплоя важен

Схема БД и код приложения, который её использует, должны быть совместимы в каждый момент деплоя — продакшн-трафик не останавливается ради миграции.

Два правила:

1. Аддитивное изменение (новая колонка, которую читает новый код): запустите миграцию до деплоя кода. Старый код игнорирует новую колонку; новый код находит её готовой.
2. Удаление (дроп колонки, которую читает старый код): деплойте новый код первым, дождитесь, пока старый код сдренируется, затем запустите миграцию. Иначе старый код запрашивает несуществующую колонку и падает.

Однотранзакционные миграции, удаляющие или переименовывающие колонки за один шаг — классический deploy-coupled баг; фикс — разбить изменения на безопасные аддитивные шаги (урок 05).