Cómo aceleramos en 90 por ciento la ejecución de nuestras migraciones en Rails
En Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, automatización y servicios de inteligencia de negocio con power bi, afrontamos un reto común en proyectos Rails de larga duración: miles de migraciones acumuladas que ralentizan la creación de nuevos entornos y complican el cambio de branch. En nuestro caso, con años de historial y varios bancos de datos con el mismo esquema, reconstruir la base y preparar entornos nuevos se había vuelto demasiado lento. Aquí explicamos cómo lo resolvimos reduciendo en torno al 90 por ciento el tiempo de db migrate, y cómo puedes aplicar esta estrategia en tu organización.
El problema de base es conocido: cuanto más crece el número de migraciones, más tarda su ejecución secuencial. Rails ejecuta cada migración en su propia transacción para proteger la consistencia, algo correcto en producción, pero costoso cuando necesitas levantar entornos desde cero con frecuencia. Además, al cambiar de branch tras ejecutar migraciones, el archivo schema.rb puede quedar con restos de otras ramas y forzarte a recrear toda la base. Por último, la verificación de Rails se basa en timestamps guardados en la tabla schema_migrations; si el timestamp ya está en la tabla, esa migración se salta, lo que permite marcar manualmente como ejecutadas ciertas migraciones en entornos concretos.
Notamos algo clave: la tarea schema load es muy rápida, mucho más que ejecutar todas las migraciones. Sin embargo, no es suficiente para producción porque no crea vistas ni ejecuta código Ruby de las migraciones. Si en el historial había SQL para crear views o bloques Ruby que generaban registros, no queríamos perderlos. El desafío fue entonces combinar la velocidad de cargar estructura con la seguridad de no omitir cambios de datos imprescindibles.
Antes, una advertencia importante: esta solución cambia el enfoque clásico de Rails y te ata al adaptador de base de datos actual porque se apoya en un archivo SQL. Pierdes parte del carácter agnóstico que ofrece el schema.rb. Si no sufres migraciones lentas o necesitas un historial reversible impecable, quizá no sea tu mejor opción.
Nuestra estrategia fue construir una línea base en SQL con todas las migraciones antiguas y dejar las recientes tal cual para conservar su reversibilidad. Elegimos como corte final de 2024. Todo lo anterior se consolidó en un único structure sql de referencia, y todo lo de 2025 en adelante siguió como migraciones normales.
Primer escollo: el structure sql no incluye inserciones o actualizaciones de datos que algunas migraciones realizan. Aunque lo ideal es que los equipos dupliquen esa lógica en seeds.rb, en la práctica no siempre ocurre. Para detectar qué migraciones tocaban datos, instrumentamos temporalmente el proceso de migración para registrar SQLs de tipo insert, update o delete y asociarlos a la migración que los disparó. Con ese log pasamos de miles de migraciones a unas 70 para revisar manualmente. Movimos la lógica que actuaba como seed al archivo db seeds.rb y dejamos las migraciones antiguas libres de efectos de datos.
Con la parte de datos despejada, generamos la línea base SQL. Cambiamos de forma temporal el formato de esquema a SQL, apartamos las migraciones posteriores a 2024 para que no se ejecutaran, reconstruimos la base y renombramos el structure sql resultante como structure baseline sql. Después eliminamos las migraciones previas a 2025 y devolvimos las nuevas a la carpeta de migraciones.
Para enlazar esa línea base con el flujo normal de Rails, creamos una migración con timestamp al final de 2024 que se encarga de cargar el archivo structure baseline sql. Insertamos ese timestamp en la tabla schema migrations de todos los entornos existentes para que dicha migración se considere ya ejecutada y solo se aplique en entornos nuevos. El cuerpo de la migración simplemente lee y ejecuta el SQL del baseline. Opcionalmente desactivamos la transacción de DDL en esta migración, exclusivamente para entornos nuevos, con el objetivo de acelerar la carga; si algo fallaba, bastaba con recrear la base del entorno nuevo.
Tras eso, devolvimos el formato de esquema a Ruby para seguir manteniendo el schema.rb con el resto de migraciones futuras. Al ejecutar de nuevo db migrate nos encontramos con dos detalles prácticos. Primero, Rails intentaba recrear las tablas de sistema ar internal metadata y schema migrations. Para evitar choques, ajustamos el SQL del baseline añadiendo condiciones del tipo if not exists en las sentencias de creación y en la adición de claves primarias, o alternativamente, se pueden eliminar esos bloques del archivo porque Rails los gestiona por su cuenta. Segundo, en algunos entornos fue necesario eliminar del baseline la línea de comentario sobre la extensión pg trgm debido a permisos de usuario restringidos.
Con estos ajustes, el flujo quedó así: en entornos nuevos, la migración de fin de 2024 carga de un golpe toda la estructura consolidada con vistas y extensiones, y luego se ejecutan únicamente las migraciones recientes. En entornos existentes, esa migración se considera ya aplicada y el equipo continúa con el ciclo normal. El resultado fue una reducción de tiempos cercana al 90 por ciento al levantar o reconstruir bases, lo que aceleró la creación de ambientes de desarrollo, pruebas y staging.
Recomendaciones y buenas prácticas que aprendimos en el proceso: asegurarse de que todos los entornos han ejecutado todas las migraciones incluidas en el baseline antes de eliminar los archivos antiguos, mantener un seeds.rb completo y probado, validar el baseline en un entorno intermedio antes de producción, y documentar claramente el punto de corte y el procedimiento de actualización del baseline si se repite en el futuro. Si trabajas con varias bases o con funciones específicas de tu motor, revisa cuidadosamente las diferencias en extensiones, vistas y permisos.
Si tu equipo necesita llevar esta optimización a la práctica o quiere revisar su arquitectura de migraciones, en Q2BSTUDIO podemos ayudarte desde el diseño de software a medida hasta la modernización de pipelines y datos. Descubre cómo abordamos proyectos de aplicaciones a medida y software a medida en nuestro servicio de desarrollo de aplicaciones y software multiplataforma, y cómo potenciamos la productividad con inteligencia artificial e IA para empresas, agentes IA y automatización inteligente de procesos.
Además de acelerar migraciones Rails, ofrecemos ciberseguridad y pentesting, servicios cloud aws y azure, servicios inteligencia de negocio con power bi, analítica avanzada y gobierno de datos. Si buscas una estrategia integral para escalar con seguridad y eficiencia, somos tu socio tecnológico.