Cómo aceleramos en 90 % la ejecución de migraciones en Rails y lo que aprendimos en Q2BSTUDIO
En Q2BSTUDIO, empresa de desarrollo de software, creamos aplicaciones a medida y software a medida para clientes que exigen velocidad, seguridad y escalabilidad. Tras seis años acumulando migraciones en un proyecto grande, reconstruir bases de datos y levantar nuevos entornos era lento y costoso. Aquí compartimos el proceso con el que logramos un ahorro cercano al 90 % en el tiempo de db migrate, manteniendo la coherencia de datos y reduciendo fricciones de desarrollo.
El problema de base era doble. Por un lado, cada migración en Rails se ejecuta en su propia transacción y de forma secuencial, lo que se vuelve muy lento cuando tienes cientos o miles. Por otro, al alternar ramas, el schema.rb podía contaminarse con restos de otras ramas y forzaba a recrear la base completa. Además, teníamos varios entornos que comparten el mismo esquema y su creación se volvía lenta, encareciendo la puesta en marcha de entornos de prueba y preproducción.
Optimizar el código de migraciones ayuda, pero no cambia el orden de magnitud. Detectamos que schema load era muchísimo más rápido que ejecutar todas las migraciones, pero tenía dos limitaciones serias: no crea vistas y no ejecuta código Ruby dentro de migraciones que insertan o actualizan datos. También recordamos cómo Rails decide si una migración ya se ejecutó o no. Usa la tabla schema_migrations para comprobar el timestamp de cada migración. Si existe, la salta. Esto significa que puedes marcar migraciones como aplicadas añadiendo su timestamp a esa tabla sin necesidad de que el archivo exista en la carpeta migrate. Ese detalle fue clave en nuestra estrategia.
La meta fue clara: cargar un esquema base con velocidad de archivo SQL, sin perder la capacidad de crear los datos imprescindibles que antes estaban en migraciones. Advertencia importante antes de continuar: al trabajar con structure.sql pierdes la agnosticidad de base de datos que aporta schema.rb y renuncias a una parte del historial reversible. No es una vía oficial de Rails y solo la recomendamos si tu cuello de botella es real y significativo.
Nuestra solución partió de un baseline. Decidimos convertir a SQL todas las migraciones hasta 2024, y dejar que las de 2025 en adelante siguieran como migraciones normales. Antes, necesitábamos localizar qué migraciones realizaban inserciones, actualizaciones o borrados. Teníamos miles, así que instrumentamos el proceso de migración con un pequeño registrador que solo corría durante db migrate y registraba toda sentencia SQL de tipo insert, update o delete. Con ese filtro, pasamos de miles a unas 70 candidatas para revisar.
Con esa lista reducida movimos al archivo db seeds.rb todo lo que en realidad era lógica de datos necesaria para entornos nuevos. Casos típicos eran tareas históricas como actualizar flags masivos o crear registros iniciales que ya no tenían razón de existir en entornos productivos, pero que en entornos nuevos sí deben existir, por lo que deben vivir en las seeds.
Después generamos el baseline SQL. Añadimos en application.rb el formato SQL para exportar estructura, movimos temporalmente las migraciones posteriores a 2024 fuera de la carpeta para que no se ejecutaran, recreamos la base y obtuvimos el structure.sql resultante. Renombramos ese archivo a structure_baseline.sql y devolvimos las migraciones recientes a su sitio. Luego eliminamos del repositorio todas las migraciones previas a 2025, ya consolidadas en el baseline.
Para integrar el baseline en el flujo normal, generamos una migración con timestamp de finales de 2024 que simplemente carga el contenido de structure_baseline.sql. Insertamos manualmente ese timestamp en la tabla schema_migrations de todos los entornos existentes, de modo que en entornos ya operativos se marque como ejecutada y se salte, pero en entornos nuevos se ejecute y cargue el esquema completo en segundos. Es imprescindible verificar que todos los entornos han ejecutado previamente esas migraciones históricas antes de consolidarlas en SQL.
Usamos la carga del archivo SQL sin transacción para maximizar velocidad. Este enfoque tiene riesgos, por lo que lo limitamos a entornos nuevos, donde recrear la base no es un problema si algo falla. Puedes optar por transaccionar en productivo o condicionar la desactivación de la transacción al entorno local.
Durante las pruebas surgió un detalle con las tablas internas de Rails ar_internal_metadata y schema_migrations, que el SQL baseline intentaba recrear. Ajustamos el archivo baseline para añadir condiciones del tipo si no existe al crear tablas e índices. Alternativamente, puedes eliminar por completo esas secciones ya que Rails se encarga de ellas, pero conviene validar con tu adaptador. También eliminamos comentarios sobre extensiones si el usuario de base de datos no tiene permisos para comentarlas.
Tras aplicar el baseline en entornos nuevos y devolver el formato del esquema a ruby si así lo prefieres, db migrate volvió a funcionar con normalidad, y el tiempo total de preparación de la base se redujo en torno al 90 %. Hoy podemos crear entornos nuevos con mucha mayor rapidez y movernos entre ramas sin dolor, algo crítico en equipos de desarrollo que entregan con frecuencia.
Resumen operativo de la estrategia que nos funcionó
Identifica migraciones que modifican datos con un registro temporal de sentencias insert update delete durante db migrate. Mueve la lógica de datos duraderos a db seeds.rb. Exporta structure.sql como baseline hasta un corte claro de fecha. Crea una migración con timestamp previo al corte que cargue structure_baseline.sql y márcala como ejecutada en entornos existentes insertando su timestamp en schema_migrations. Ajusta el baseline para evitar recrear tablas internas e índices si ya existen. Decide si necesitas desactivar la transacción solo en entornos nuevos para maximizar velocidad.
En Q2BSTUDIO transformamos cuellos de botella técnicos en ventaja competitiva. Si tu organización necesita acelerar pipelines, modernizar plataformas y construir soluciones robustas, nuestro equipo de software a medida y aplicaciones a medida puede ayudarte de principio a fin. Conectamos arquitectura de datos, automatización y despliegues en la nube con prácticas de ciberseguridad, inteligencia artificial e inteligencia de negocio para que la entrega sea rápida y segura.
Descubre cómo abordamos proyectos complejos de software a medida desde la ideación hasta el despliegue con un enfoque integral en escalabilidad, rendimiento y gobierno de datos en nuestro servicio de desarrollo de aplicaciones y software multiplataforma. Y si buscas impulsar la velocidad de tus entornos y escalar infraestructuras elásticas, nuestros servicios cloud aws y azure integran automatización, observabilidad y seguridad desde el primer día.
También diseñamos soluciones con inteligencia artificial para empresas, agentes IA y analítica avanzada con power bi, junto a prácticas de ciberseguridad y pentesting, para que tus datos y modelos estén protegidos mientras aceleras la toma de decisiones con servicios de inteligencia de negocio. Si necesitas una estrategia de ia para empresas que se conecte con tus sistemas y procesos, cuéntanos tu reto.
Palabras clave que trabajamos en este enfoque y que forman parte de nuestro día a día: aplicaciones a medida, software a medida, inteligencia artificial, ia para empresas, agentes IA, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi. Si quieres replicar esta optimización o llevar tu plataforma al siguiente nivel, estamos listos para ayudarte.