Cómo gestionar migraciones de base de datos sin dramas
- base de datos
- migraciones
- software
- prisma
- sql
Las migraciones de base de datos son uno de esos puntos en el desarrollo donde el riesgo de romper algo es alto. Un cambio en el esquema que parece inofensivo en desarrollo puede paralizar una aplicación en producción. No es solo mover datos; es asegurar que la aplicación sigue funcionando con el nuevo modelo sin perder información.
El objetivo es actualizar la estructura de la base de datos de forma controlada. Esto incluye añadir tablas, modificar columnas o cambiar relaciones. Un proceso mal gestionado puede significar downtime, corrupción de datos o una deuda técnica que arrastrarás durante meses.
Versionado del esquema para la gestión de migraciones
La única forma de gestionar migraciones de forma segura es versionar el esquema de tu base de datos. Esto implica tener un historial de todos los cambios aplicados, permitiendo saber en qué estado se encuentra la base de datos y cómo llegar a él. Herramientas como Prisma, Flyway o Alembic hacen esto por ti, generando archivos de migración que se aplican secuencialmente.
Cuando un cliente me llega con problemas de “la base de datos no cuadra”, el 90% de las veces es por falta de un sistema de migraciones robusto. Mi regla es que cada cambio en el esquema debe ser un paso de migración explícito y reversible. Para estrategias de refactorización seguras, consulta refactorizar sin romper.
Con Prisma, por ejemplo, el flujo es claro:
- Modificas tu
schema.prisma. - Generas una nueva migración con
npx prisma migrate dev --name add_new_feature. - Aplicas esa migración en producción con
npx prisma migrate deploy.
npx prisma migrate dev --name add_new_feature
Este comando crea un nuevo archivo SQL en tu directorio de migraciones y lo aplica a tu base de datos de desarrollo. Luego, en producción, prisma migrate deploy se encarga de aplicar solo las migraciones pendientes.
Migraciones SQL manuales: cuando lo automático no basta
Aunque herramientas como Prisma facilitan mucho el trabajo, hay situaciones donde necesitas escribir las migraciones SQL a mano. Esto ocurre, por ejemplo, cuando la transformación de datos entre un esquema y otro es compleja. Una herramienta automática puede añadir una columna, pero no sabe cómo rellenarla con datos derivados de otras tablas.
Necesitas un control granular sobre la lógica de transformación. En estos casos, puedes seguir usando el framework de migraciones de tu elección, pero editas el SQL generado o creas un archivo de migración vacío para rellenarlo con tu lógica.
Un ejemplo de migración manual para rellenar una nueva columna:
-- migration.sql
ALTER TABLE "public"."usuarios" ADD COLUMN "nombre_completo" TEXT;
UPDATE "public"."usuarios"
SET "nombre_completo" = "nombre" || ' ' || "apellido"
WHERE "nombre_completo" IS NULL;
ALTER TABLE "public"."usuarios" ALTER COLUMN "nombre_completo" SET NOT NULL;
Es un proceso que requiere más atención y conocimiento del esquema SQL.
Tradeoffs: herramientas automáticas vs. SQL puro
La elección de la estrategia de migraciones requiere análisis. Cada enfoque tiene sus ventajas y complicaciones.
| Característica | Herramientas automáticas (Prisma, Flyway) | Migraciones SQL puro |
|---|---|---|
| Complejidad | Baja para cambios de esquema básicos | Alta, requiere más conocimiento SQL |
| Control | Menor, dependen de la lógica de la herramienta | Total, granularidad absoluta |
| Velocidad | Rápida para generar y aplicar cambios | Lenta, requiere escribir y revisar cada SQL |
| Errores | Menos en cambios de esquema, más en transformaciones de datos | Más fácil introducir errores humanos |
| Rollback | Generan scripts de deshacer (Prisma) o requieren revertir manualmente | Requiere scripts de rollback manuales y mucha cautela |
La seguridad de los datos no es negociable. El coste de una migración fallida en producción es siempre mayor que el tiempo invertido en una buena estrategia.
El testing es obligatorio en migraciones
Es necesario probar las migraciones en un entorno clonado de producción. No es suficiente que funcione en tu máquina de desarrollo. Debes simular el proceso completo: desde la aplicación de la migración hasta la validación de que la aplicación funciona correctamente con el nuevo esquema. Esto incluye la ejecución de tests automatizados y pruebas manuales de funcionalidades críticas.
Cuando un cliente me plantea un cambio de esquema importante, siempre le insisto en que el entorno de staging debe ser un espejo casi perfecto de producción. Es la forma de detectar problemas antes de que impacten a usuarios reales.
La planificación del rollback en migraciones
Una buena migración no solo tiene un plan de “cómo ir hacia adelante”, sino también de “cómo ir hacia atrás” si algo sale mal. Esto implica tener un backup reciente y verificado de la base de datos justo antes de aplicar la migración. También significa que las migraciones deben ser diseñadas para ser reversibles en la medida de lo posible.
En algunos casos, un rollback puede ser tan simple como revertir el código y la base de datos al estado anterior. Sin embargo, si la migración incluye una transformación de datos irreversible, el rollback se complica y podría requerir una estrategia de deploys sin miedo a rollback más elaborada. Es una capa extra de seguridad necesaria.
Gestionar migraciones de base de datos requiere disciplina y herramientas adecuadas. Si quieres asegurar la estabilidad de tu software, el testing automatizado te ahorra dinero a largo plazo, especialmente en entornos de producción. Y para entender cómo estas decisiones de esquema impactan la evolución de tu sistema, es útil revisar cómo versionar una API sin romperla, ya que muchos de los principios son aplicables.
Técnico freelance especializado en desarrollo a medida, automatizaciones con IA y gestión técnica para negocios en España. Más sobre mí →
¿Necesitas desarrollo a medida?
Desarrollo funcionalidades específicas, integraciones entre sistemas y herramientas internas. Si se puede programar, probablemente puedo hacerlo.