présentation

La question de savoir si Postgres est suffisant pour les besoins de la plupart des équipes est souvent débattue. L'article Postgres is enough soutient que la plupart des équipes utilisent trop de microservices et de bases de données, ce qui entraîne une surcharge opérationnelle, des coûts plus élevés et une complexité accrue.

contexte technique

Les équipes ont souvent tendance à ajouter de nouvelles bases de données et microservices pour répondre à des besoins spécifiques, tels que le caching avec Redis, la recherche full-text avec Elasticsearch ou les tâches en arrière-plan avec Sidekiq. Cependant, cela peut entraîner une augmentation de la surface d'attaque opérationnelle, avec plusieurs systèmes à déployer, à sauvegarder, à surveiller et à sécuriser.

architecture et limites

Postgres offre de nombreuses fonctionnalités qui peuvent répondre à la plupart des besoins, telles que le caching, la recherche full-text et les tâches en arrière-plan. Avant de recourir à une autre base de données, il est recommandé de voir si Postgres peut déjà répondre à ces besoins. Si Postgres n'est pas suffisant, il est important de documenter les raisons pour lesquelles il est insuffisant et d'accepter les coûts opérationnels de l'alternative.

implications et limites

Il est important de noter que seules 0,3% des projets logiciels atteignent réellement le niveau de « webscale ». Les entreprises qui servent des millions d'utilisateurs, comme Notion, Netflix et Instagram, font confiance à des technologies « ennuyeuses » comme Postgres. Il est donc probable que les startups puissent se passer d'une architecture à sept bases de données. Il est recommandé de ne recourir à d'autres bases de données que lorsque Postgres est réellement insuffisant et que les coûts opérationnels de l'alternative sont acceptés.