Planificador de Migracion de Base de Datos

El Problema

Necesitas renombrar una columna, pero tu app sirve 10,000 solicitudes por minuto. Un ALTER TABLE ingenuo bloquea la tabla, corta conexiones y tumba tu servicio. Las migraciones de base de datos son la parte mas peligrosa de cualquier despliegue — son irreversibles, destruyen datos y ocurren en el componente mas critico. Una migracion incorrecta puede corromper datos, romper compatibilidad hacia atras o bloquear tablas por horas.

El Prompt

Eres un experto en migraciones de base de datos especializado en cambios de esquema sin tiempo de inactividad. Planifica mi migracion de forma segura.

DETALLES DE LA MIGRACION:
- Base de datos: [ej., PostgreSQL 16, MySQL 8, MongoDB 7]
- ORM/Herramienta: [ej., Prisma, Knex, Django ORM, TypeORM, SQL crudo]
- Cambio necesario: [ej., renombrar columna, agregar columna NOT NULL, dividir tabla, cambiar tipo de dato]
- Tamaño de tabla: [ej., 1M filas, 100M filas, desconocido]
- Trafico durante migracion: [ej., lectura intensiva, escritura intensiva, mixto, se puede programar ventana de mantenimiento]
- Configuracion de replicacion: [ej., primary unico, primary + read replicas, multi-primary]

Planifica la migracion:
1. **Evaluacion de riesgo**: Califica el nivel de peligro (bajo/medio/alto/critico) y explica por que.
2. **Estrategia multi-fase**: Divide la migracion en fases seguras usando el patron expand-contract.
3. **Compatibilidad hacia atras**: Asegura que ambas versiones de codigo funcionen durante la transicion.
4. **Backfill de datos**: Como poblar nuevas columnas/tablas sin bloquear o sobrecargar la base de datos.
5. **Plan de rollback**: Como revertir cada fase si algo sale mal.
6. **Monitoreo**: Que metricas de base de datos observar durante la migracion.
7. **Scripts de migracion**: El codigo SQL o de ORM exacto para cada fase.

Ejemplo de Salida

Migracion: Renombrar columna "name" → "full_name" en tabla users (50M filas)
Riesgo: ALTO — renombrar directamente bloquea la tabla, rompe todas las queries que referencian "name"

Fase 1 (Deploy 1): Agregar nueva columna
  ALTER TABLE users ADD COLUMN full_name VARCHAR(255);
  — Ambas columnas vieja ("name") y nueva ("full_name") coexisten

Fase 2 (Deploy 2): Escritura dual en codigo de aplicacion
  — Escribir en ambas columnas, leer de "name" (compatible con codigo viejo)

Fase 3 (Background): Backfill de datos existentes
  — UPDATE users SET full_name = name WHERE full_name IS NULL (lotes de 10,000)

Fase 4 (Deploy 3): Cambiar lecturas a nueva columna
Fase 5 (Deploy 4): Eliminar columna vieja

Cuando Usarlo

Usa este skill para cualquier cambio de esquema en una base de datos de produccion que sirve trafico en vivo — renombrar columnas, cambiar tipos, agregar constraints NOT NULL, dividir o fusionar tablas. Especialmente critico para tablas con millones de filas donde las operaciones ALTER TABLE pueden bloquear por minutos.

Consejos Pro

• Nunca agregues una columna NOT NULL sin default — en tablas grandes, ALTER TABLE ADD COLUMN NOT NULL reescribe cada fila y bloquea la tabla. Agrega la columna como nullable primero, haz backfill, luego agrega el constraint.
• Prueba migraciones contra datos de tamaño de produccion — una migracion que corre en 2 segundos en tu BD de desarrollo con 100 filas podria bloquear 30 minutos en produccion con 50 millones de filas.
• Usa advisory locks para scripts de backfill — previene que multiples procesos de backfill corran simultaneamente, lo cual puede sobrecargar la base de datos.
• Siempre ten un rollback probado — practica el rollback en staging antes de ejecutar en produccion. “Siempre podemos restaurar del backup” no es un plan de rollback, es una plegaria.