Cuando empiezas a desarrollar una app es natural inclinarse por lo que conoces bien. Para nosotros, SQL era “la vieja confiable”. Su estructura robusta y familiar nos daba seguridad para avanzar rápido en las primeras etapas. ¿Quién no ama una buena base de datos relacional, con sus relaciones perfectamente organizadas y esas consultas complejas que te hacen sentir como un maestro Jedi de los datos?

Sin embargo, a medida que la aplicación crece y evoluciona, esa misma rigidez y estructura que antes era una ventaja se fue volviendo una limitación. Así fue como “la vieja confiable” empezó a darnos más dolores de cabeza que tranquilidad.

La decisión de migrar

Nuestra app había crecido y mutado bastante desde su nacimiento. El modelo de datos se había vuelto un monstruo difícil de manejar. Creamos tablas intermedias para cosas pequeñas, empezamos a usar jsonb para almacenar datos que no cabían en las estructuras tradicionales y a borrar registros bajo condiciones específicas que añadían más complejidad de la necesaria.

Nos dimos cuenta de que estábamos forzando nuestra base de datos relacional más allá de sus límites naturales.

Ahí fue cuando apareció MongoDB como solución. Este cambio a NoSQL nos ofrecía ventajas que SQL simplemente no podía darnos:

1. Esquemas flexibles: podíamos agregar o quitar campos sin tener que rediseñar toda la estructura de la base de datos.
2. Consultas más simples: algunas operaciones eran mucho más intuitivas en MongoDB que en SQL.
3. Escalabilidad horizontal: a medida que crecíamos, podíamos distribuir los datos entre múltiples servidores con mayor facilidad.

El problema estaba claro: SQL ya no era lo que necesitábamos para el futuro de nuestra app.

Simplificando la complejidad

Nuestro antiguo diagrama entidad-relación (ERD) en SQL se había vuelto un verdadero laberinto. Cada nueva funcionalidad requería más tablas, más relaciones, más joins. Tratar de entender cómo funcionaban todas esas pequeñas tablas era casi como estar resolviendo bugs constantemente, pero sin que realmente hubiera errores de código.

Nuestro diagrama en SQL se veía algo así:

Después de una buena cantidad de sesiones de modelado, logramos simplificar nuestro esquema de datos y reducir el número de "tablas" en más de un 50%. El resultado era un modelo más claro, más eficiente y mucho más fácil de manejar.

Así se veía el nuevo diagrama con MongoDB:

El impacto

Esta nueva estructura nos permitió:

• Consultas más rápidas: obtener los detalles de una validación ahora es cuestión de buscar un solo documento.
• Código más limpio: nos deshicimos del laberinto de relaciones complejas.
• Mayor flexibilidad: agregar o eliminar atributos es tan fácil como modificar un documento, sin necesidad de migraciones. Incluso podemos anidar documentos completos dentro de otros.

Como todo en la vida, esto también tiene sus desventajas.

Si no somos cuidadosos, la flexibilidad de MongoDB puede introducir inconsistencias o errores difíciles de detectar. Pero aprendimos a navegar estos desafíos:

• Control de la flexibilidad: Usamos tipado de documentos para evitar inconsistencias.
• Consultas optimizadas: Implementamos índices para mejorar el rendimiento de ciertas búsquedas frecuentes.
• Manejo de inconsistencias: Creamos migraciones de datos para campos que perdieron formato en la migración.

Cómo migrar de SQL a MongoDB

Si alguna vez has tenido que migrar una base de datos en producción, sabes que no es algo que quieras hacer un viernes en la tarde. Es un proceso complejo, en el que muchas cosas pueden fallar:

• Existe el riesgo de que algunos datos no se migren o se corrompan durante la transferencia.
• Una mala planificación o un tiempo de migración mal calculado puede dejar a la aplicación fuera de servicio, afectando a los usuarios.
• Cambiar la estructura de la base de datos puede romper las consultas existentes, ya que las relaciones y esquemas cambian significativamente

A pesar de esto, lo logramos y nuestra app no dejó de funcionar ni un solo momento.

Aquí te cuento cómo lo hicimos, paso a paso:

1. Preparación y pruebas

Desarrollamos y probamos scripts para migrar los datos de PostgreSQL a MongoDB. Probamos, ajustamos y volvimos a probar para estar absolutamente seguros.

2. Primera migración:

Movimos todos los datos existentes a MongoDB, pero seguimos operando con PostgreSQL. Durante unos minutos, nuestra app vivió en un estado de Schrödinger, coexistiendo en SQL y NoSQL.

3. El gran switch:

Cambiamos el código para que Mongoid reemplazara a ActiveRecord y, desde ese momento, nuestra app empezó a trabajar con MongoDB.

4. Segunda migración:

Justo después del switch, migramos nuevamente para capturar cualquier dato nuevo generado entre la primera migración y el cambio.

5. Verificación y ajustes:

Revisamos que todo funcionara bien. Último paso: respirar tranquilos y celebrar.

Este proceso nos permitió realizar una migración sin tiempo de inactividad y sin pérdida de datos. Se sintió como cambiarle las ruedas a un auto en movimiento.

El después

Meses después de la migración, no tenemos dudas: fue la decisión correcta. Redujimos los bugs, simplificamos las consultas y el tiempo que nos toma introducir cambios en el modelo de datos se ha reducido considerablemente.

Por ejemplo, antes, modificar la estructura de una tabla en SQL nos obligaba a hacer migraciones complejas y coordinadas, mientras que ahora, con MongoDB, agregar un nuevo campo a un documento es tan simple como incluirlo en una actualización. También, las consultas que antes requerían múltiples joins ahora se resuelven con una única consulta a un documento anidado.

Migrar de SQL a NoSQL no fue fácil, pero el resultado ha sido un sistema más ágil, flexible y escalable.

Si estás considerando hacer un cambio similar, evalúa tus necesidades, planifícalo bien y no temas adaptarte. Al final, el esfuerzo vale la pena.

Y aunque SQL siempre será “la vieja confiable”, a veces lo mejor es abrazar lo nuevo.