- A Infisical cresceu rapidamente como uma plataforma que processa mais de 50 milhões de Secrets por dia
- Com o aumento do uso, foi necessário continuar atualizando a stack, e recentemente foi realizada uma migração completa do banco de dados do MongoDB para o PostgreSQL
- Essa migração envolveu um processo complexo de adoção de nova tecnologia, criação de esquema de banco de dados, reestruturação da lógica, reescrita de consultas e transferência de milhões (ou bilhões) de registros de dados para o PostgreSQL
Etapa inicial
- Quando a Infisical foi criada pela primeira vez, a equipe escolheu a stack com a qual tinha mais familiaridade: MongoDB + Mongoose ORM
- No início, o foco estava mais no Infisical Cloud, a oferta de SaaS gerenciado, e não se esperava muito que os usuários hospedassem o produto por conta própria
Por que não o MongoDB?
- O MongoDB funcionou bem no começo, mas, à medida que os casos de uso do produto foram além do serviço gerenciado, as desvantagens começaram a aparecer
- Muitas organizações passaram a preferir hospedar o Infisical por conta própria em vez de usar o Infisical Cloud, e algumas precisavam atender requisitos on-premises
- Por causa das limitações e problemas de usabilidade do MongoDB, decidiu-se migrar para o PostgreSQL
Por que escolher o PostgreSQL?
- Ao procurar um novo banco de dados, fatores como facilidade de administração, suporte a transações e recursos relacionais foram considerados importantes
- Houve uma avaliação entre soluções de armazenamento internas e externas, mas a escolha final foi o PostgreSQL
- O PostgreSQL oferece uma comunidade ativa, documentação abundante, várias soluções e extensões, além de serviços gerenciados oferecidos pela maioria dos provedores de nuvem
Sobre o ORM
- Depois de escolher o PostgreSQL, foi preciso decidir como a aplicação interagiria com o banco de dados
- Procurou-se uma ferramenta que oferecesse uma experiência semelhante à do Mongoose ORM, e decidiu-se usar o query builder Knex.js
- O Knex.js fornece ferramentas de seeding e migração, e alcançou um nível satisfatório com um trabalho personalizado de integração com Zod para suporte a TypeScript
Planejamento da migração
- Quando a reescrita do código estava chegando ao fim, surgiu a questão de como realizar a migração mapeando os dados do MongoDB para o PostgreSQL com a menor interrupção possível
- No caso da Infisical, que desempenha um papel em infraestrutura crítica, downtime era absolutamente inaceitável, e o compromisso adotado foi proibir operações de escrita durante o período de migração
A grande mudança
- Para se preparar para a migração, foi elaborado um checklist detalhado e um cronograma estimado
- A migração foi realizada permitindo apenas operações de leitura por 6 horas e, após a movimentação dos dados, o DNS foi apontado para a nova instância
Resultado
- A migração ocorreu sem perda de dados e, em até 36 horas, foram corrigidos alguns erros de funcionalidade com impacto mínimo para os clientes
- A plataforma teve melhora de desempenho graças à otimização de consultas com joins, e os custos de banco de dados também caíram 50%
- Com a adoção do PostgreSQL, a validação de dados melhorou, e agora ficou muito mais fácil fazer self-hosting do Infisical
Conclusão
- A decisão de migrar do MongoDB para o PostgreSQL não foi fácil, e levou de 3 a 4 meses com planejamento cuidadoso e discussões
- Recomenda-se pensar profundamente sobre o caso de uso e a implementação antes de tentar um projeto grande como esse
1 comentários
Comentários do Hacker News
Um usuário com experiência operando Postgres e MongoDB em grande escala disse que gosta de ambos os bancos, mas não consegue entender a falta de suporte a alta disponibilidade (HA) e escalabilidade horizontal no Postgres. Ele apontou que cada instalação de Postgres acaba sendo única e precisa ser complementada com várias extensões e scripts. Acrescentou que essas extensões frequentemente têm muitos bugs e pouca documentação. Também mencionou que as mudanças no formato de arquivo entre versões principais do Postgres tornam os upgrades muito difíceis. Disse estar surpreso com o fato de o MySQL ser muito melhor que o Postgres em HA/sharding.
Foi compartilhado um post de blog que descreve a experiência de migração de MongoDB para PostgreSQL de um ponto de vista técnico. Foi mencionado que esse post é mais técnico e menos voltado ao lado de negócios, incluindo exemplos e gráficos.
Um usuário que comentou que o PostgreSQL está dominando o mundo dos bancos de dados apontou que os autores escolheram no início uma arquitetura inadequada para o modelo de dados. Disse que colocar dados relacionais em um armazenamento não relacional sempre causará problemas.
Foi apontada uma contradição entre a frase de que a escolha de MongoDB e do ORM Mongoose foi otimizada para aumentar a velocidade de desenvolvimento de funcionalidades e a frase que justifica essa escolha com a citação de Tony Hoare: "otimização prematura é a raiz de todo mal".
Um usuário que considera bancos de dados orientados a documentos inadequados para novos projetos disse esperar aumento nos custos de licença e hospedagem do MongoDB, além de estagnação no desenvolvimento de funcionalidades.
Um usuário que trocou para Postgres por causa dos problemas causados pelo MongoDB disse estar muito satisfeito com a decisão. Também acrescentou que achava incômodo o MongoDB usar JavaScript em vez de SQL.
Um usuário apontou que faltou discutir os problemas surgidos durante o processo real de reescrita e perguntou se as queries ficaram equivalentes, como o produto foi estruturado para permitir leitura e escrita nos dois bancos, se bugs foram encontrados durante a migração e se foi possível migrar as queries em uma relação 1:1.
Um usuário que já usou MongoDB disse que bancos de dados orientados a documentos servem para alguns casos de uso, mas que, quando se percebe a necessidade de usar o Mongoose, é hora de considerar migrar para um banco relacional. Aconselhou que, na maioria dos casos, o Mongoose é algo a ser adicionado a um projeto existente, e que, se ele for necessário desde o começo, o melhor é usar um banco relacional.
Um usuário que herdou um projeto que usa MongoDB disse que o formato BSON não é bom, mas gosta da possibilidade de usar o mesmo esquema do JSON API até o banco de dados. Acrescentou que isso combina bem com programação orientada a dados em Go e Rust. Concluiu que o MongoDB só é adequado para cargas predominantemente de leitura e que, quando há muitas escritas, ele não ajuda muito.
Um usuário disse que o principal motivo da mudança para PostgreSQL não foi técnico, mas relacionado a licenciamento, e compartilhou que obteve melhora de desempenho graças à otimização de queries com joins. Também mencionou que, como os dados não estavam modelados de forma adequada para um armazenamento chave-valor, migrar para o tipo de armazenamento correto foi o motivo decisivo.