- L’auto-hébergement de Postgres n’est ni complexe ni risqué, et constitue une approche moins coûteuse qu’un service managé, avec une plus grande liberté d’ajustement des performances
- La plupart des services de base de données cloud exploitent une version légèrement modifiée de Postgres open source, la différence réelle se situant surtout dans le niveau d’automatisation de l’exploitation
- Dans des cas d’exploitation réels, Postgres auto-hébergé traite de façon stable des milliers d’utilisateurs et des dizaines de millions de requêtes, avec un temps de maintenance très réduit
- En raison de la hausse des prix des services managés comme AWS RDS, il est possible d’exploiter soi-même un serveur bien plus puissant pour le même coût
- Pour les équipes de taille intermédiaire dont la gestion d’infrastructure n’est pas trop complexe, l’auto-hébergement devient une alternative réaliste en matière de coût et de performances
Changement du récit centré sur le cloud
- Autrefois, la plupart des entreprises exploitaient directement leurs bases de données sur leurs propres serveurs, une architecture rapide avec peu de latence réseau
- Dans les années 1980 à 2000, il était fréquent que le serveur applicatif et le serveur de base de données se trouvent sur la même machine physique
- La sortie d’Amazon RDS (2009) a été perçue comme une proposition séduisante, automatisant sauvegardes, correctifs et supervision
- Au départ, cela permettait de réduire la charge d’exploitation pour un coût proche de celui d’un serveur dédié
- Après 2015, avec l’accélération de l’adoption du cloud, l’idée que gérer soi-même son infrastructure était inefficace s’est largement diffusée
- Le modèle où AWS gère l’infrastructure tandis que les développeurs se concentrent sur la logique applicative s’est imposé comme standard
- En 2025, les prix de RDS ont fortement augmenté, au point qu’il est possible de louer un serveur dédié bien plus puissant pour le même budget
- Exemple : une instance db.r6g.xlarge (4 vCPU, 32GB RAM) coûte 328 $/mois, soit le prix de location possible d’un serveur 32 cœurs avec 256GB de RAM
Composition réelle des services managés
- AWS RDS est fondamentalement un Postgres standard auquel AWS ajoute ses propres systèmes de supervision et de sauvegarde
- Sont inclus des sauvegardes basées sur des snapshots EBS, la gestion de configuration via Chef/Puppet/Ansible, le pooling de connexions avec PgBouncer, la supervision CloudWatch et des scripts de bascule automatique
- Cette architecture n’est pas techniquement complexe ; la valeur principale réside dans l’automatisation de l’exploitation et la facilité du déploiement initial
- Lors d’une migration à configuration matérielle équivalente de RDS vers un auto-hébergement, les performances se sont révélées identiques, voire meilleures
- Il devient possible d’ajuster directement des paramètres limités dans RDS afin d’optimiser les performances
Complexité d’exploitation de l’auto-hébergement
- La migration vers un serveur DigitalOcean de 16 vCPU / 32GB RAM / 400GB de disque a pris environ 4 heures, puis l’exploitation s’est montrée stable
- Les gammes de produits à haute disponibilité nécessitent environ 30 minutes d’administration par mois, et les services à faible trafic peuvent être entièrement automatisés
- Cycle de maintenance régulier
- Hebdomadaire (10 min) : vérification des sauvegardes, revue des logs de requêtes lentes, contrôle de l’espace disque
- Mensuel (30 min) : mises à jour de sécurité, vérification de la politique de rétention des sauvegardes, planification de capacité
- Trimestriel (2 h) : mise à jour des tableaux de bord de supervision, optimisation de la configuration, tests de restauration
- La gestion des incidents reste de votre responsabilité, mais RDS connaît aussi des pannes et, au final, les développeurs doivent également intervenir
- En exploitation directe, on peut choisir soi-même le moment des mises à jour et les zones de risque, ce qui facilite la maîtrise de la stabilité
Cas où l’auto-hébergement n’est pas adapté
- Pour des développeurs débutants qui veulent créer rapidement un prototype, un service managé est plus simple
- Les grandes entreprises peuvent avoir intérêt à employer des ingénieurs base de données dédiés ou à déléguer au cloud pour réduire les coûts humains
- Dans les secteurs réglementés (PCI-DSS, HIPAA, etc.), l’usage de plateformes managées certifiées peut être requis
Principaux points de configuration
- Réglages mémoire : il faut ajuster
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem, etc. en fonction du matériel
- Exemple :
shared_buffers à 25 % de la RAM, effective_cache_size à 75 %
- Gestion des connexions : configurer un pooling avec
pgbouncer, pour un fonctionnement efficace dans des environnements Python asyncio
- Exemple de configuration de base :
max_connections = 200, log_connections = on
- Tuning du stockage : sur NVMe SSD, régler
random_page_cost = 1.1, effective_io_concurrency = 200, etc.
- L’amélioration des performances en lecture aléatoire permet d’optimiser le planificateur de requêtes
- Réglages WAL : ajuster notamment
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 pour l’équilibre entre durabilité et performances
Conclusion
- Il n’est pas nécessaire d’exploiter soi-même toute son infrastructure, mais Postgres fait partie des domaines où l’auto-hébergement est raisonnable
- Si vous dépensez plus de 200 $/mois sur RDS, cela vaut la peine de tester la migration d’une base non critique vers un serveur de test
- À l’avenir, l’infrastructure pourrait évoluer vers une forme hybride mêlant services managés et auto-hébergement
- Postgres est considéré comme un excellent candidat à l’auto-hébergement en termes de rapport coût/efficacité
Aucun commentaire pour le moment.