Риски миграций, сгенерированных ИИ

Изменение схемы базы данных может иметь большой негативный эффект, выходящий за рамки локальной правки. Например, неудачный ALTER TABLE способен поставить в очередь запросы ко всей таблице, съесть пул соединений и превратить локальную правку схемы в отказ сервиса. 😱

Генерировать изменения схемы стало почти бесплатно, а стоимость проверки не уменьшилась, что повышает общий риск. При работе с PostgreSQL важно помнить, что CREATE INDEX обычное построение блокирует записи в таблицу до завершения, тогда как CONCURRENTLY позволяет продолжать INSERT, UPDATE и DELETE. И не забывайте, что CREATE INDEX CONCURRENTLY нельзя выполнять внутри обычного transaction block.

Безопасность операции определяется не размером SQL и не временем её выполнения на staging, а тем, с какими блокировками и с каким текущим трафиком она столкнётся. Поэтому для DDL разумно задавать небольшой lock_timeout, чтобы миграция упала, а не ждала блокировку бесконечно. ⏳

В идеале, процесс должен выглядеть так: AI предлагает изменение и объясняет риск; CI проверяет формальные правила; DB показывает реальное поведение DDL; а человек принимает решение там, где нужен контекст production. И самое главное — полезнее смотреть на то, сколько миграций CI остановил до deploy, а не на количество сгенерированных файлов. 💪