Migraciones de base de datos sin drama
Cambiar el esquema de una base de datos en producción da miedo. Pero con el proceso correcto, las migraciones pueden ser rutina en lugar de evento de pánico.
Por qué las migraciones dan miedo
Es código que modifica datos en producción. Si algo sale mal, no es un bug que se arregla con un hotfix. Es potencialmente datos perdidos o corruptos.
El miedo es razonable. Pero el miedo sin proceso lleva a evitar migraciones necesarias o a hacerlas de forma apresurada.
El principio fundamental
Cada migración debe ser reversible o aplicable incrementalmente. Nunca cambios destructivos en un solo paso.
Si añades una columna, la migración inversa la elimina. Si cambias un tipo de dato, primero añades la columna nueva, luego migras datos, luego eliminas la vieja.
Migraciones no destructivas
Añadir columnas es seguro. Eliminar columnas es destructivo.
El patrón seguro: primero deja de usar la columna en el código, despliega, luego elimina la columna en una migración posterior.
Renombrar tablas o columnas es destructivo. El patrón seguro: crea la nueva, copia datos, actualiza código para usar ambas, despliega, luego elimina la vieja.
El problema de los deploys largos
Si tu aplicación tiene múltiples instancias y el deploy tarda minutos, durante ese tiempo hay instancias corriendo código viejo y código nuevo.
Las migraciones deben ser compatibles con ambas versiones. La columna nueva debe tener default o permitir null hasta que todo el código nuevo esté desplegado.
Testing de migraciones
Las migraciones se pueden testear. Aplica la migración en un clon de producción. Verifica que el código funciona. Verifica que la migración inversa funciona.
Es más trabajo, pero menos trabajo que restaurar un backup a las 3am.
Migraciones grandes
Cambios que tocan millones de filas no pueden hacerse en una transacción. El lock de la tabla tumbaría el servicio.
El patrón: scripts que procesan en batches, con pausas entre batches para no saturar. Pueden tardar horas o días. El código debe funcionar con datos parcialmente migrados.
Herramientas que ayudan
Sistemas de migraciones versionadas: cada migración tiene un identificador único, se aplican en orden, se registra cuáles están aplicadas.
Prisma, Drizzle, Flyway, Alembic. La herramienta importa menos que usarla consistentemente.
El proceso que funciona
Cada cambio de esquema es un PR separado con su migración. La migración se revisa como cualquier otro código.
En staging se aplica la migración completa antes de merge. En producción se aplica como parte del deploy.
Backups antes de migraciones significativas. Aunque tengas confianza en el proceso, el seguro existe por algo.
Cuándo hacer excepciones
Proyectos nuevos sin usuarios pueden hacer migraciones destructivas directamente. La cautela escala con la criticidad de los datos.
Pero los hábitos que formas en proyectos pequeños son los que tendrás cuando los datos importen. Mejor practicar el proceso correcto siempre.