Antes de entrar de lleno a como cambiamos tan rápido de una base de datos NoSQL a una SQL, es importante dar las razones por las cuales lo hicimos.

Como contexto, he usado Mongo intermitentemente desde 2015 aproximadamente y siempre me ha gustado mucho la flexibilidad que te da al inicio de una idea.

De hecho aquí hay un extracto de un pequeño Gabriel de 17 años pitchando algo técnico por primera vez en un escenario lleno y como se puede ver Mongo siempre ha estado presente.

Pero volviendo al punto de la flexibilidad de Mongo, esta ventaja inicial se vuelve una desventaja al momento de intentar tener un sistema más robusto y con consistencia en sus datos.

Aún sí, esta no fue la razón por la cual nos tuvimos que cambiar en tiempo record, sino que fue una perdida total de la base de datos al momento de escalar nuestro cluster de Mongo. Catastrófico pero nos sirvió de excusa para migrar la aplicación completa y los backups a Postgres.

La abstracción como héroe de la historia

A mi parecer la obsesión con las abstracciones y código DRY que tiene la industria de desarrollo es un error la mayoría de las veces. Dicho esto, la abstracción que sí considero completamente justificable es el acceso a los datos, dado que lógica de negocios no debería tener dependencia en la base de datos a usar.

Esquema Data-Access Layer (fuente)

Nuestro diseño fue crear una clase abstracta llamada DataService que dictara que métodos van a tener que implementar cada adaptador (Mongoose, TypeORM, Prisma… etc).

Extracto del adaptador de Prisma a nuestro DataService

La migración

En total la creación de este nuevo adapter con Prisma usando Postgres fueron aproximadamente unas 200 lineas de código, a lo que se sumó un par de horas de testeo manual y un script de migración de la data de Mongo a Postgres. Si bien el sistema fue diseñado para que una migración fuese así de sencilla, incluso nosotros quedamos impactados con lo bien que funcionó (incluyendo temas como transacciones y otros).

El aprendizaje

La migración de Payscript de MongoDB a PostgreSQL tuvo un origen fortuito pero sirvió para poner en práctica patrones de diseños y tuvo el efecto colateral de mejorar significativamente el rendimiento de algunas queries.

Como desarrolladores debemos siempre poner en la balanza el avanzar el producto tan rápido como sea (generando deuda técnica) vs parchar o prevenir deuda técnica (frenando desarrollo de producto). Esto es un ejercicio que debemos ir evaluando frecuentemente ya que si acumulamos mucha deuda técnica terminará frenando la velocidad de desarrollo y la capacidad de crear nuevas features, mientras que si tomamos demasiado tiempo en desarrollar un código perfecto puede que ya no exista la startup 😬