Comparatif des opérateurs Kubernetes pour PostgreSQL

EDIT 16/05/2024 : ajout de commentaires notamment sur CrunchyData/postgres-operator.

Dans le cadre de ce comparatif, après avoir effectué plusieurs recherches et après avoir collecté les avis de mes pairs, la liste des sélectionnés est la suivante :

Pour comparer ces différents opérateurs, examinons quelques critères clés tels que la facilité d’utilisation, la prise en charge des fonctionnalités avancées de PostgreSQL, la robustesse et la communauté de support.

Facilité d’utilisation, dans son ensemble

zalando/postgres-operator : conçu avec une attention particulière à l’automatisation et à la simplification des tâches d’administration, il offre une expérience utilisateur fluide une fois la configuration initiale effectuée. Comme pour d’autres, il respecte les règles du Cloud Native.
CrunchyData/postgres-operator : il est connu pour sa documentation approfondie et ses outils abordables, cette solution offre une expérience utilisateur agréable pour le déploiement et la gestion des clusters PostgreSQL. Le respect des règles du Cloud Native est bien présent.
cloudnative-pg/cloudnative-pg : il est construit sur l’opérateur de Crunchy Data (CrunchyData/postgres-operator), il propose quelque chose de similaire similaire. Sponsorisé par CNCF, nous pouvons nous attendre à un maintien certain. Avec CNCF derrière, on peut s’attendre à ce que la solution soit Cloud Native ready.
perco/percona-postgresql-operator : offre une installation et une configuration relativement simples avec des guides détaillés. La configuration initiale peut nécessiter une certaine expertise, mais une fois configuré, il est facile à gérer. Un WebPanel peut être déployé pour faciliter sa gestion. Lui aussi, respecte les prérequis Cloud Native.
sorintlab/stolon : Bien qu’il soit puissant, son installation et sa configuration peuvent être plus complexes que d’autres solutions car nécessitant une compréhension approfondie de PostgreSQL et de Kubernetes.
ongres/stackgres : stackgres vise à simplifier le déploiement de clusters PostgreSQL sur Kubernetes en fournissant une interface conviviale et des outils d’administration simplifiés. Sponsorisé lui aussi par CNCF.

Prise en charge des fonctionnalités avancées

zalando/postgres-operator : propose une prise en charge robuste des fonctionnalités avancées de PostgreSQL, y compris la haute disponibilité et la réplication.
CrunchyData/postgres-operator : reconnu pour son support avancé des fonctionnalités de PostgreSQL telles que la sauvegarde et la restauration, la réplication, et la gestion des données volumineuses.
cloudnative-pg/cloudnative-pg : hérite des fonctionnalités avancées de PostgreSQL et de l’opérateur CrunchyData, il fournit des outils pour les déployer efficacement sur Kubernetes.
perco/percona-postgresql-operator : offre une gamme complète de fonctionnalités avancées de PostgreSQL, avec la haute disponibilité, la sauvegarde et la restauration.
sorintlab/stolon : prise en charge robuste de la haute disponibilité et de la réplication, mais peut nécessiter une configuration plus manuelle pour certaines fonctionnalités avancées.
ongres/stackgres : se concentre sur la prise en charge des fonctionnalités avancées de PostgreSQL tout en simplifiant leur gestion sur Kubernetes.

Robustesse et communauté de support

zalando/postgres-operator : bien que développé par Zalando, il peut avoir une communauté de support légèrement plus petite que d’autres solutions plus établies.
CrunchyData/postgres-operator : bénéficie du soutien de Crunchy Data, une entreprise spécialisée dans les solutions PostgreSQL, avec une solide communauté et un support professionnel disponible.
cloudnative-pg/cloudnative-pg : profite de l’expertise de Crunchy Data et de sa base d’utilisateurs, offrant ainsi un support fiable et une communauté active.
perco/percona-postgresql-operator : soutenu par Percona, une entreprise bien établie dans le domaine des bases de données open source, avec une communauté active.
sorintlab/stolon : projet inactif depuis 2021 ! Faire attention car la communauté n’est que peu active.
ongres/stackgres : projet plus récent, il gagne en popularité mais peut avoir une communauté de support plus réduite par rapport aux solutions plus anciennes.

Informations diverses

Opérateur	Stars	Fréquence commits	Fréquence de mise à jour
`zalando/postgres-operator`			6 mois
`CrunchyData/postgres-operator`			inconnu
`cloudnative-pg/cloudnative-pg`			1 à 2 mois
`perco/percona-postgresql-operator`			Varie entre 1 mois et 6 mois
`sorintlab/stolon`			Aucune depuis 2021
`ongres/stackgres`			1 mois

A noter

EDIT 16/05/2024

Après avoir discuté de ce comparatif avec d’autres professionnels, un expert DB et notamment de PostgreSQL m’a prévenu de quelque chose d’important : des conditions d’utilisation obscures sont placées sur l’opérateur CrunchyData. Ces conditions sont indirectes car elles ne s’appliquent pas à l’opérateur mais au PostgreSQL modifié par CrunchyData utilisé dans l’opérateur (source). Ces règles plutôt dissimulées empêchent l’utilisation de l’opérateur dans une structure de plus de 50 salariés si vous ne possédez pas de licence. Percona, se basant en partie sur l’opérateur CrunchyData, a réussi à faire en sorte de ne pas vous exposer à ce problème. Cependant, rien ne dit que les conditions d’utilisation de CrunchyData ne vont pas évoluer dans le futur, empêchant Percona de fonctionner dans ces conditions.

Concrètement, il s’agit des Developer Terms of Use, appliqué aux logiciels CrunchyData. Il serait logique de penser qu’il ne s’agit de conditions d’utilisation applicables seulement à des environnements de développement, mais c’est là que la subtilité réside. L’opérateur PGO est pourtant sous licence Apache 2.0. Malgré cela, on peut lire dans le repo Github :

The use of container images downloaded from the Crunchy Data Developer Portal are subject to the Crunchy Data Developer Program terms.
https://github.com/CrunchyData/postgres-operator

Attention donc à ces choix.

Conclusion

En résumé, on constate surtout que les solutions sont souvent propulsées soit par un besoin interne dans une société (je pense à Zalando), soit par une entreprise proposant des services autour de PostgreSQL. Dans tous les cas, le choix de l’opérateur Kubernetes pour PostgreSQL dépendra des besoins spécifiques de votre projet, de votre niveau de confort avec Kubernetes et PostgreSQL, ainsi que de la disponibilité des ressources de support et de la communauté. Chaque opérateur a ses propres forces et faiblesses, donc une évaluation approfondie est recommandée avant de prendre une décision.