¿Cómo publicarías un cambio de esquema de base de datos que rompe compatibilidad sin tiempo de caída?

Usa el patrón de expandir y contraer. Primero expande: añade la columna o tabla nueva de forma retrocompatible para que el código desplegado actualmente siga funcionando. Luego despliega código que escriba en la vieja y en la nueva, rellena las filas existentes en lotes pequeños, cambia las lecturas a la forma nueva y solo en una release posterior elimina la columna antigua. Mantén cada migración compatible con la versión de la aplicación que corre antes y después de ella.

La regla que mantengo es que cualquier esquema desplegado tiene que funcionar con la versión anterior y con la siguiente del código, porque durante un despliegue progresivo ambas corren a la vez. Así que nunca renombro una columna, expando y contraigo. Digamos que estamos separando un campo de nombre. La primera migración añade las columnas nuevas anulables, que es barato y no toca ninguna fila existente. Luego una release donde la aplicación escribe en la forma vieja y en la nueva pero sigue leyendo la vieja, así que nada de cara al usuario depende todavía de los datos nuevos. Después un relleno ejecutándose en lotes de unos pocos miles con una pausa entre ellos, para no mantener una transacción larga ni disparar el retraso de replicación en las réplicas. Luego una release que lee las columnas nuevas, con las viejas todavía escribiéndose como vía de escape. Solo cuando eso lleva estable una release o dos dejo de escribir en las dos y elimino las columnas antiguas. También mantengo las migraciones fuera de la propia ruta de despliegue, y cualquier cosa que tome un bloqueo pesado, como construir un índice, corre de forma concurrente y fuera de horas punta.