Como você entregaria uma mudança de schema de banco que quebra compatibilidade sem downtime?

Use o padrão expandir e contrair. Primeiro expanda: adicione a coluna ou tabela nova de forma retrocompatível para que o código atualmente implantado continue funcionando. Depois implante um código que escreve no formato antigo e no novo, preencha as linhas existentes em lotes pequenos, mude as leituras para o formato novo, e só em um release posterior remova a coluna antiga. Mantenha toda migração compatível com a versão da aplicação que roda antes e depois dela.

A regra que eu sigo é que qualquer schema implantado tem que funcionar com a versão anterior e com a próxima do código, porque durante um rolling deploy as duas estão rodando ao mesmo tempo. Então eu nunca renomeio uma coluna, eu expando e contraio. Digamos que a gente esteja dividindo um campo de nome. A primeira migração adiciona as colunas novas anuláveis, o que é barato e não toca em nenhuma linha existente. Depois um release em que a aplicação escreve no formato antigo e no novo mas ainda lê o antigo, então nada voltado ao usuário depende dos dados novos ainda. Depois um preenchimento rodando em lotes de alguns milhares com uma pausa entre eles, para eu não segurar uma transação longa nem estourar o atraso de replicação nas réplicas. Depois um release que lê as colunas novas, com as antigas ainda sendo escritas como saída de emergência. Só depois de aquilo ficar estável por um ou dois releases é que eu paro a escrita dupla e removo as colunas antigas. Eu também mantenho as migrações fora do caminho do deploy em si, e qualquer coisa que pegue um lock pesado, como construir um índice, roda de forma concorrente e fora do pico.