- Infisical a connu une croissance rapide en tant que plateforme traitant plus de 50 millions de secrets par jour
- Avec l’augmentation de l’usage, l’entreprise a dû faire évoluer en continu sa stack, et a récemment mené une migration complète de sa base de données de MongoDB vers PostgreSQL
- Cette migration a impliqué un processus complexe comprenant l’adoption de nouvelles technologies, la création du schéma de base de données, la refonte de la logique, la réécriture des requêtes et le transfert de millions (voire de milliards) d’enregistrements vers PostgreSQL
Premières étapes
- Lors de la création initiale d’Infisical, l’équipe a choisi la stack qu’elle maîtrisait le mieux : MongoDB + Mongoose ORM
- Au départ, l’accent était davantage mis sur Infisical Cloud, une offre SaaS managée, et l’équipe ne s’attendait pas vraiment à voir de nombreux utilisateurs auto-héberger le produit
Pourquoi pas MongoDB ?
- MongoDB a bien fonctionné au début, mais à mesure que les cas d’usage du produit ont dépassé le cadre du service managé, ses limites ont commencé à apparaître
- De nombreuses organisations ont préféré auto-héberger Infisical plutôt que d’utiliser Infisical Cloud, et certaines devaient aussi répondre à des exigences on-premise
- En raison des contraintes et des problèmes d’utilisabilité de MongoDB, la décision a été prise de passer à PostgreSQL
Pourquoi choisir PostgreSQL ?
- Dans la recherche d’une nouvelle base de données, la facilité d’administration, la prise en charge des transactions et les capacités relationnelles ont été considérées comme des critères importants
- L’équipe a hésité entre une solution de stockage interne et une solution de stockage externe, mais a finalement retenu PostgreSQL
- PostgreSQL offre une communauté active, une documentation riche, de nombreuses solutions et extensions, et des services managés chez la plupart des fournisseurs cloud
À propos de l’ORM
- Après avoir choisi PostgreSQL, il fallait décider de la manière dont l’application interagirait avec la base de données
- L’équipe a cherché un outil offrant une expérience proche de Mongoose ORM et a choisi d’utiliser le query builder Knex.js
- Knex.js fournit des outils de seeding et de migration, et le résultat a atteint un niveau jugé satisfaisant grâce à un travail d’intégration personnalisée de Zod pour la prise en charge de TypeScript
Plan de migration
- Alors que la réécriture du code touchait à sa fin, l’équipe s’est demandé comment exécuter une migration permettant de mapper les données MongoDB vers PostgreSQL avec un minimum d’interruption
- Dans le cas d’Infisical, qui joue un rôle dans des infrastructures critiques, aucun downtime n’était acceptable, et un compromis a été trouvé en interdisant les opérations d’écriture pendant la migration
Le grand basculement
- Pour préparer la migration, une checklist détaillée et un calendrier prévisionnel ont été établis
- La migration a été réalisée sur une fenêtre de 6 heures en mode lecture seule, puis le DNS a été basculé vers la nouvelle instance une fois les données déplacées
Résultats
- La migration s’est déroulée sans perte de données, et quelques bugs fonctionnels à impact client limité ont été corrigés dans les 36 heures
- La plateforme a gagné en performances grâce à l’optimisation des requêtes via les jointures, et les coûts de base de données ont aussi baissé de 50 %
- L’adoption de PostgreSQL a amélioré la validation des données, et Infisical est désormais bien plus facile à auto-héberger
Conclusion
- La décision de passer de MongoDB à PostgreSQL n’a pas été simple, et a nécessité 3 à 4 mois de planification et de discussions approfondies
- Il est recommandé de réfléchir en profondeur à ses cas d’usage et à son implémentation avant de se lancer dans un projet de cette ampleur
1 commentaires
Avis Hacker News
Un utilisateur ayant de l’expérience dans l’exploitation à grande échelle de Postgres et de MongoDB dit apprécier les deux bases de données, mais ne pas comprendre l’absence de prise en charge native de la haute disponibilité (HA) et du scale-out horizontal dans Postgres. Il souligne qu’une installation Postgres est toujours particulière et qu’il faut compenser cela avec diverses extensions et scripts. Il ajoute que ces extensions sont souvent boguées et mal documentées. Il mentionne aussi que les changements de format de fichiers entre versions majeures de Postgres rendent les mises à niveau très difficiles. Il se dit surpris que MySQL soit bien meilleur que Postgres sur la HA et le sharding.
Partage un billet de blog décrivant, sous un angle technique, une migration de MongoDB vers PostgreSQL. Il précise que ce billet est plus technique et moins orienté business, avec des exemples et des graphiques.
Un utilisateur affirmant que PostgreSQL est en train de dominer le monde des bases de données fait remarquer que les auteurs avaient au départ choisi une architecture inadaptée à leur modèle de données. Il note que mettre des données relationnelles dans un stockage non relationnel finit toujours par poser problème.
Souligne la contradiction entre l’affirmation selon laquelle le choix de MongoDB et de l’ORM Mongoose était optimisé pour accélérer le développement des fonctionnalités, et la justification de ce choix à l’aide de la citation de Tony Hoare : « l’optimisation prématurée est la racine de tous les maux ».
Un utilisateur qui estime que les bases de données orientées documents ne conviennent pas aux nouveaux projets prévoit une hausse des coûts de licence et d’hébergement de MongoDB, ainsi qu’une stagnation du développement de ses fonctionnalités.
Un utilisateur ayant déjà basculé vers Postgres à cause de problèmes liés à MongoDB dit être très satisfait de cette décision. Il ajoute que l’usage de JavaScript par MongoDB à la place de SQL lui paraissait peu pratique.
Un utilisateur fait remarquer qu’il manque une discussion sur les problèmes rencontrés pendant la réécriture réelle. Il pose des questions sur l’équivalence des requêtes, sur la manière dont le produit a été configuré pour pouvoir lire et écrire sur les deux bases de données, sur la découverte éventuelle de bugs pendant la migration, et sur la possibilité de migrer les requêtes en 1:1.
Un utilisateur ayant utilisé MongoDB explique que les bases de données orientées documents conviennent à certains cas d’usage, mais que lorsqu’on réalise qu’il faut utiliser Mongoose, il faut envisager de passer à une base de données relationnelle. Il conseille que, dans la plupart des cas, Mongoose soit ajouté à un projet existant, et que s’il est nécessaire dès le départ, il vaut mieux choisir une base de données relationnelle.
Un utilisateur ayant hérité d’un projet utilisant MongoDB dit ne pas aimer le format BSON, mais apprécier le fait de pouvoir utiliser le même schéma depuis l’API JSON jusqu’à la base de données. Il ajoute que cela convient bien à la programmation orientée données en Go et en Rust. Il conclut que MongoDB n’est adapté qu’aux charges surtout en lecture et qu’en cas de nombreuses écritures, MongoDB n’aide pas beaucoup.
Un utilisateur indique que le passage à PostgreSQL était motivé principalement par des questions de licence plutôt que par des raisons techniques, et partage avoir constaté un gain de performance grâce à l’optimisation de requêtes avec des jointures. Il ajoute que, comme les données n’étaient pas modélisées d’une manière adaptée à un stockage clé-valeur, le passage à un type de stockage approprié a été le facteur décisif.