Миграции ломаются не из-за SQL, а из-за хаоса в порядке и ответственности

Миграции ломаются не из-за SQL, а из-за хаоса в порядке и ответственности

Если schema changes живут в ручных правках, рано или поздно появится разъезд между dev, staging и prod. Для supabase и postgres это особенно больно: одна забытая таблица, одно `ALTER` не там — и auth, rls, edge-функции начинают вести себя как будто у них разные базы.

Правила, которые реально держат миграции в узде:
• одна миграция = одна логическая задача, без «заодно поправил ещё 5 мест»
• миграции должны быть идемпотентны там, где это возможно: `IF EXISTS`, `IF NOT EXISTS`
• RLS-политику и индексы не смешивай в один большой ком, если потом нужно быстро искать причину сбоя
• не полагайся на ручной порядок файлов: у миграций должен быть один понятный источник истины

Отдельно проверь вещи, которые чаще всего забывают: расширения, `default`-значения, триггеры, grant'ы и зависимости между таблицами. Если ты меняешь колонку, подумай, что будет с существующими строками, с `auth.uid()` в policy и с запросами, которые ждут старую форму данных.

Хорошая миграция — это не просто SQL, а способ сделать схему воспроизводимой. Если после `reset` база собирается в тот же вид без ручных действий, значит порядок, rls и postgres-логика у тебя уже под контролем.