Миграция схемы базы данных без даунтайма для postgresql на примере django

[Golem765]

Разве drop table/column будет безопасной операцией, если вы говорите что хотите поддерживать работу старых машин которые ещё не успели обновиться?

[kalininmr]

тоже смутило.
хотя ежели проверками все обвесить.

[tbicr]

Минимум на чём пробовал — postgres 9.4, более старые чесно говоря не смотрел. Не подскажите на какой версии это не работает?

На 9.4+ если с таблицей никто не работает, то можно считать операцию безопасной, иначе зачем удалять. Если с колонкой никто не работает, то тоже можно считать безопасной, так как отрабатывает мгновенно, согласно документации www.postgresql.org/docs/current/static/sql-altertable.html колонка не удаляется физически, а помечается удалённй, потом место будет очищено через AUTO VACUUM.

При удалении таблицы/колонки все машинки сперва перестают работать с таблицей/колонкой, только потом накатывается миграция, назвал это обратным порядок выкатки в тексте.

[tekdel]

Мы хоть используем ruby on rails, но в целом у нас похожий подход:

В случае rename column

1. Миграция по созданию новой column
2. Backfill + изменение бизнес логики на работу с новой column ( deploy )
3. Удаление column

И так в прицнипе со всем, даже с таблицами, что-то новое, backfill + deploy бизнес логики и потом удаление. Можно конечно заметить, что старые инстансы будут еще работать со старой column/table, но в прицнипе backfill можно повторить.

[Anthrax_Beta]

у варианта «С Даунтаймом» нужен грустный смалик.