prisma migrate deploy en una tabla de 50 millones de registros es decir "qué podría salir mal" en producción. Esa migración tan inocente que localmente tomó 200 milisegundos, en producción con un índice que se reconstruye, una columna que se llena con default, y requests concurrentes golpeando la misma tabla, puede tomar 40 minutos de lock exclusivo. Cuarenta minutos durante los cuales ningún usuario puede loguearse, ningún pago se procesa, y el canal de Slack de operaciones se llena de capturas de pantalla de errores 500.
El problema no es Prisma. Es cualquier migración naive contra una tabla grande en producción. Postgres y MySQL tienen operaciones que bloquean la tabla completa mientras corren: agregar una columna con default no nullable, cambiar el tipo de una columna, renombrar algo que está referenciado. Si corrés esas operaciones contra una tabla de millones de filas y un load balancer que no para de mandar tráfico, el sistema se congela.
El patrón que resuelve esto no es nuevo. Se llama expand-contract (también conocido como parallel change) y es la técnica estándar que usan equipos como GitHub, Shopify y Stripe para cambiar esquemas sin cortar el servicio. La idea: cada migración se divide en cuatro fases pequeñas que individualmente son seguras, corren en segundos, y se pueden desplegar gradualmente con feature flags.
En este artículo aprenderás:
- Qué operaciones bloquean la tabla en PostgreSQL y cuáles no (la lista corta y exacta)
- El patrón expand-contract en 4 fases: Expand → Migrate → Contract → Cleanup, con ejemplo real en Prisma
- Backfill batched para mover datos de una columna vieja a una nueva sin saturar la base de datos
- Rollback seguro en cada fase si algo falla a mitad del deploy
- Checklist de migración que usamos antes de tocar producción
