- Infisical ha crecido rápidamente hasta convertirse en una plataforma que procesa más de 50 millones de secretos al día
- A medida que aumentó el uso, tuvieron que seguir actualizando su stack, y recientemente realizaron una migración completa de base de datos de MongoDB a PostgreSQL
- Esta migración incluyó un proceso complejo de adopción de nuevas tecnologías, creación del esquema de base de datos, reestructuración de la lógica, reescritura de consultas y traslado de millones (o decenas de miles de millones) de registros de datos a PostgreSQL
Etapa inicial
- Cuando construyeron Infisical por primera vez, eligieron MongoDB + Mongoose ORM usando el stack con el que el equipo estaba más familiarizado
- Al principio, estaban más enfocados en Infisical Cloud, su oferta SaaS administrada, y no esperaban muchos casos en los que los usuarios alojaran el producto por su cuenta
¿Por qué no MongoDB?
- MongoDB funcionó bien al inicio, pero a medida que los casos de uso del producto fueron más allá del servicio administrado, sus desventajas empezaron a hacerse evidentes
- Muchas organizaciones preferían alojar Infisical por su cuenta en lugar de usar Infisical Cloud, y algunas además necesitaban cumplir requisitos on-premise
- Debido a las limitaciones y problemas de usabilidad de MongoDB, decidieron cambiarse a PostgreSQL
¿Por qué eligieron PostgreSQL?
- Al buscar una nueva base de datos, factores como facilidad de administración, soporte de transacciones y capacidades relacionales se consideraron importantes
- Evaluaron entre una solución de almacenamiento interna y soluciones de almacenamiento externas, pero eligieron PostgreSQL
- PostgreSQL ofrece una comunidad activa, documentación abundante, una gran variedad de soluciones y extensiones, y la mayoría de los proveedores de nube ofrecen servicios administrados
Sobre el ORM
- Después de elegir PostgreSQL, tuvieron que decidir cómo interactuaría la aplicación con la base de datos
- Buscaron una herramienta que ofreciera una experiencia similar a Mongoose ORM y decidieron usar el query builder Knex.js
- Knex.js proporciona herramientas de seeding y migraciones, y llegaron a un nivel satisfactorio mediante trabajo personalizado de integración con Zod para soporte de TypeScript
Plan de migración
- Cuando la reescritura del código estaba por terminar, pensaron cómo ejecutar una migración que mapeara los datos de MongoDB a PostgreSQL con la menor interrupción posible
- En el caso de Infisical, que cumple un papel en infraestructura crítica, no podían permitir ningún downtime, así que optaron por la concesión de bloquear las operaciones de escritura durante el periodo de migración
La gran mudanza
- Para prepararse para la migración, elaboraron una checklist detallada y un cronograma estimado
- La migración se realizó durante 6 horas permitiendo solo operaciones de lectura, y después de mover los datos cambiaron el DNS a la nueva instancia
Resultado
- La migración avanzó sin problemas y sin pérdida de datos, y corrigieron en menos de 36 horas algunos errores funcionales con impacto mínimo para los clientes
- La plataforma experimentó mejoras de rendimiento gracias a la optimización de consultas mediante joins, y los costos de base de datos también se redujeron en 50%
- La adopción de PostgreSQL mejoró la validación de datos, y ahora es mucho más fácil autohospedar Infisical
Conclusión
- La decisión de pasar de MongoDB a PostgreSQL no fue sencilla; tomó entre 3 y 4 meses de planificación cuidadosa y discusiones
- Recomiendan pensar a fondo en el caso de uso y la implementación antes de intentar un proyecto grande de este tipo
1 comentarios
Opiniones de Hacker News
Un usuario con experiencia operando Postgres y MongoDB a gran escala comenta que le gustan ambas bases de datos, pero que no puede entender la falta de soporte de Postgres para alta disponibilidad (HA) y escalado horizontal. Señala que cada instalación de Postgres es única y que hay que compensar eso con varias extensiones y scripts. Agrega que esas extensiones suelen tener muchos bugs y poca documentación. También menciona que los cambios en el formato de archivos entre versiones mayores de Postgres hacen que las actualizaciones sean muy difíciles. Le sorprende que MySQL sea mucho mejor que Postgres en HA/sharding.
Comparte una publicación de blog que describe la experiencia de migrar de MongoDB a PostgreSQL desde una perspectiva técnica. Menciona que el post es más técnico y menos orientado al negocio, e incluye ejemplos y gráficos.
Un usuario que dice que PostgreSQL está conquistando el mundo de las bases de datos señala que los autores eligieron al principio una arquitectura que no encajaba con su modelo de datos. Menciona que poner datos relacionales en un almacén no relacional siempre causará problemas.
Señala la contradicción entre la afirmación de que elegir MongoDB y el ORM Mongoose fue una decisión optimizada para acelerar el desarrollo de funcionalidades, y la frase que justifica esa elección con la cita de Tony Hoare: "la optimización prematura es la raíz de todos los males".
Un usuario que cree que las bases de datos documentales no son adecuadas para proyectos nuevos espera que aumenten los costos de licencia y hosting de MongoDB y que el desarrollo de funcionalidades se estanque.
Un usuario que cambió a Postgres por problemas causados por MongoDB menciona que está muy satisfecho con esa decisión. Agrega que le resultaba incómodo que MongoDB usara JavaScript en lugar de SQL.
Un usuario señala que faltó hablar de los problemas surgidos durante el proceso real de reescritura, y pregunta si las consultas quedaron equivalentes, cómo configuraron el producto para poder leer y escribir en ambas bases de datos, si se descubrieron bugs durante la migración y si pudieron trasladar las consultas 1:1.
Un usuario que ha usado MongoDB comenta que una base de datos documental puede servir para algunos casos de uso, pero que cuando te das cuenta de que necesitas usar Mongoose, deberías considerar cambiar a una base de datos relacional. Aconseja que, en la mayoría de los casos, Mongoose se agrega a proyectos existentes, y que si lo necesitas desde el inicio, deberías usar una base de datos relacional.
Un usuario que heredó un proyecto que usa MongoDB comenta que el formato BSON no le parece bueno, pero le gusta que se pueda usar el mismo esquema desde la API JSON hasta la base de datos. Agrega que funciona bien para programación orientada a datos en Go y Rust. Concluye que MongoDB solo es adecuado para cargas principalmente de lectura, y que no ayuda mucho cuando hay muchas escrituras.
Un usuario menciona que la razón principal para cambiar a PostgreSQL no fue técnica sino de licencias, y comparte que experimentó mejoras de rendimiento gracias a la optimización de consultas con joins. Añade que, como los datos no estaban modelados de forma adecuada para un almacén clave-valor, cambiar a un tipo de almacenamiento apropiado fue la razón decisiva.