🧱 Миграции без боли: как обновлять БД безопасно и без простоя

Сохраняй себе: в реальных проектах миграции - это не “ALTER TABLE и поехали”, а зона риска.

Один неверный шаг = даунтайм, блокировки и откат вручную.

Правильный принцип:
делай миграции так, чтобы приложение могло пережить оба состояния схемы - до и после изменения.

Рабочая стратегия (2 шага)
1) Сначала добавляй новое, не ломая старое
- добавляй новые колонки/таблицы
- не удаляй и не переименовывай сразу
- не делай NOT NULL без дефолта

2) Потом переключай код
- сначала раскатываешь схему
- потом деплоишь код, который пишет/читает новое
- и только после этого убираешь старое

Это называется “expand → migrate → contract” и это стандарт продакшн-миграций.

Фишки, которые спасают на проде
- всегда делай миграцию идемпотентной (IF EXISTS / IF NOT EXISTS)
- не держи транзакцию долго
- избегай тяжёлых ALTER на больших таблицах
- проверяй количество строк, прежде чем апдейтить
- делай бэкап/дамп перед большим изменением

-- safe-migration.sql

-- 1) EXPAND: добавляем новое, не ломая старое
ALTER TABLE users
ADD COLUMN IF NOT EXISTS email_verified BOOLEAN DEFAULT FALSE;

CREATE INDEX IF NOT EXISTS idx_users_email
ON users(email);

-- 2) MIGRATE: переносим данные маленькими шагами (пример)
-- (в реальности делается батчами на больших таблицах)
UPDATE users
SET email_verified = TRUE
WHERE email IS NOT NULL AND email <> '';

-- 3) CONTRACT: удаляем старое только после деплоя кода
-- (делать отдельной миграцией!)
-- ALTER TABLE users DROP COLUMN old_email_flag;