Me explique como entregar uma migração de banco de dados sem downtime.

Divida em passos retrocompatíveis. Suba primeiro a mudança de schema numa forma que o código rodando tolera, como adicionar uma coluna nullable, depois suba código que escreve no antigo e no novo, faça o backfill em lotes, mude as leituras, e só derrube a coluna antiga num release posterior. Evite locks longos de tabela e sempre teste o caminho de rollback.

A regra que eu sigo é que durante um deploy gradual duas versões do código estão falando com um banco só, então cada passo tem que ser seguro para as duas. Renomear uma coluna é a armadilha clássica. Em vez disso eu expando: adiciono a coluna nova nullable na própria migração, subo código que escreve nos dois campos e ainda lê o antigo, faço backfill das linhas existentes em lotes de alguns milhares com uma pausa entre eles para a replicação não ficar para trás, aí viro as leituras no release seguinte, e só num terceiro release derrubo a coluna antiga. Especificidades do Postgres também importam. Adicionar uma constraint NOT NULL numa tabela grande pega um lock pesado, então eu adiciono a coluna nullable, faço o backfill, e depois valido a constraint separadamente. O Django te dá separate_database_and_state e migrações não atômicas quando você precisa, e eu configuro um lock_timeout curto para uma migração bloqueada falhar rápido em vez de enfileirar toda query atrás dela. Toda migração também ganha um rollback testado.