Tenés que renombrar una columna en una tabla de producción con millones de filas, sin downtime. ¿Cómo planificás la migración?

Un RENAME directo rompe la versión de la app que sigue corriendo durante el rolling deploy. Uso el patrón expand / contract: el esquema tiene que ser compatible con la versión N y con la N+1 a la vez.

Pasos (cada uno es un deploy separado):

• Expand: agregar la columna nueva, nullable y sin default costoso.
• Doble escritura: la app escribe en ambas columnas y sigue leyendo la vieja. Otra opción es un trigger temporal.
• Backfill por lotes chicos (por rango de id), con pausas, para no generar locks largos, lag de réplicas ni picos de WAL o binlog. Tiene que ser reanudable.
• Cambiar las lecturas a la columna nueva, idealmente detrás de un feature flag. Antes, verificar la consistencia entre ambas columnas.
• Dejar de escribir la columna vieja.
• Contract: cuando ninguna versión desplegada la usa, eliminar la columna vieja.

Cuidados con los locks (ejemplo en PostgreSQL):

SET lock_timeout = '3s';
ALTER TABLE clientes ADD COLUMN email_contacto text;
CREATE INDEX CONCURRENTLY idx_cli_email ON clientes (email_contacto);

Un ALTER que espera un lock bloquea a todas las consultas que llegan detrás de él, así que conviene un lock_timeout corto con reintentos. Agregar un NOT NULL o un FK en tablas grandes se hace en dos fases: primero NOT VALID y después VALIDATE. En MySQL se evalúa ALGORITHM=INSTANT/INPLACE o herramientas como gh-ost o pt-online-schema-change.

Operación: las migraciones van versionadas (Flyway, Liquibase, Alembic), se ensayan con un volumen similar al de producción y se monitorean locks, latencia y lag de réplicas. El rollback en la práctica es "hacia adelante": como cada paso es compatible con el anterior, volver la app a la versión previa no rompe nada.

Hacer el RENAME y el deploy del código juntos, asumiendo que el cambio es atómico. Hacer el backfill con un único UPDATE gigante, o ignorar que un ALTER esperando un lock puede tumbar todo el tráfico.