Revision de Migraciones

El Problema

Las migraciones son los cambios de mayor riesgo en cualquier sistema. Una migracion de esquema que agrega una columna NOT NULL sin default bloquea la tabla y falla con filas existentes. Renombrar una columna rompe cada consulta que referencia el nombre viejo — incluyendo las que corren en servidores que aun no se han actualizado. Y si algo sale mal, “solo haz rollback” frecuentemente significa perder datos.

El Prompt

Revisa la siguiente migracion por seguridad y deployment zero-downtime. Actua como un ingeniero de confiabilidad de base de datos.

BASE DE DATOS: [PostgreSQL / MySQL / MongoDB]
TAMANO DE TABLA: [ej. 50M filas en users, 200M filas en events]
DEPLOYMENT: [ej. rolling deployment, blue/green, servidor unico]
ORM: [ej. Prisma, Knex, Django, Alembic, SQL raw]

CODIGO DE MIGRACION:
[pegar archivo(s) de migracion]

CAMBIOS EN CODIGO DE APLICACION:
[pegar codigo que cambia junto con la migracion]

Evalua en estas dimensiones:

1. **Compatibilidad Retroactiva**
   - El codigo viejo puede funcionar con el nuevo esquema?
   - El codigo nuevo puede funcionar con el esquema viejo?
   - Los renombramientos se hacen como agregar-nuevo → migrar-datos → eliminar-viejo?

2. **Analisis de Locks**
   - Alguna operacion adquirira un lock exclusivo de tabla?
   - Con 50M+ filas, cuanto tardara la migracion?
   - Las actualizaciones masivas de datos estan en batches?

3. **Seguridad de Rollback**
   - Hay una migracion down() / rollback?
   - El rollback es seguro (pierde datos)?
   - Las operaciones destructivas (DROP COLUMN) estan diferidas a una migracion de limpieza?

4. **Integridad de Datos**
   - Se proporcionan defaults para nuevas columnas NOT NULL?
   - Las transformaciones de datos son idempotentes?
   - Los foreign key constraints se agregan despues de completar el backfill?

5. **Impacto en Rendimiento**
   - La migracion causara agotamiento del connection pool?
   - Las creaciones de indice usan CONCURRENTLY (PostgreSQL)?

Para cada problema, proporciona:
- **Paso**: Cual parte de la migracion
- **Riesgo**: Que sale mal en produccion
- **Severidad**: Downtime / Perdida-datos / Rendimiento / Seguridad
- **Fix**: Estrategia de migracion segura con codigo

Ejemplo de Salida

## Revision de Migraciones: 3 problemas criticos

### Riesgo de Downtime: ALTER TABLE con NOT NULL en 50M filas
Codigo: `ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL`
Riesgo: Reescribe toda la tabla. Lock exclusivo por 5-15 minutos.
Fix (migracion segura en 3 fases):
  -- Fase 1: Agregar columna nullable (instantaneo, sin lock)
  ALTER TABLE users ADD COLUMN phone VARCHAR(20);
  -- Fase 2: Rellenar en batches (sin lock)
  UPDATE users SET phone = 'desconocido' WHERE phone IS NULL AND id BETWEEN $1 AND $2;
  -- Fase 3: Establecer NOT NULL
  ALTER TABLE users ALTER COLUMN phone SET NOT NULL;

Cuando Usar

Ejecutar en cada migracion antes de que toque staging, especialmente para tablas con mas de 1M filas. Critico para equipos con rolling deployments donde codigo viejo y nuevo deben coexistir.

Tips Pro

• Siempre incluir tamanos de tabla — una migracion segura con 1,000 filas puede ser catastrofica con 10,000,000.
• Probar en copia de produccion — “Genera un plan de prueba que valide esta migracion con volumen realista.”
• Cambios destructivos por fases — nunca renombrar, eliminar y agregar en la misma migracion.
• Pedir runbook — “Genera un runbook paso a paso para ejecutar esta migracion en produccion, incluyendo triggers de rollback.”