Allez-y, hébergez Postgres vous-même

 (pierce.dev)
5 points par GN⁺ 2025-12-21 | 4 commentaires | Partager sur WhatsApp
  • 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é

À lire aussi

4 commentaires

 
yangeok 2025-12-23

Le stockage garantit aussi 11 neufs, donc si on utilise le cloud, c’est justement parce que l’exploitation est difficile, comme si on le faisait soi-même sur le cloud haha
 
kaydash 2025-12-22

En réalité, exploiter un cluster à 3 nœuds ne sera probablement pas si simple.
 
GN⁺ 2025-12-21
Commentaires Hacker News

  • Je vois le self-hosting comme une question de responsabilité
    J’auto-héberge quelques produits SaaS, et c’est bien moins cher qu’AWS tout en offrant de bien meilleures performances
    En revanche, pour les projets clients, je les convaincs de payer le coût d’AWS, parce que cela permet de transférer à quelqu’un d’autre la responsabilité de la disponibilité du matériel
    Quand le budget est serré, le coût de RDS est lourd. Faire tourner un cluster Galera à 3 nœuds chez Hetzner pour quelques dollars est bien plus économique
    Mais des services managés comme Cloudflare ou SQS tombent aussi parfois en panne. Au final, la stabilité parfaite n’existe nulle part

    • J’ai demandé : « Pourquoi passer de NoNameCMS à Salesforce ? » On m’a répondu : « Si Salesforce tombe, ça finit dans le WSJ. » C’est une raison très concrète de transfert de responsabilité
    • Du point de vue des clients de ton client, dire « Ikea et Disney sont aussi tombés en panne » ne passe pas. Tout ce qui compte, c’est que leur service à eux s’est arrêté
    • Il y a AWS Serverless PG, donc il n’y a pas vraiment de raison de le gérer soi-même. Avec peu de trafic, c’est quasiment gratuit, et c’est bien supérieur en matière de sécurité, de sauvegardes et d’intégration
      AWS Aurora Serverless
    • On peut aussi choisir un compromis : externaliser jusqu’au niveau VM et gérer le reste soi-même. Tout dépend de l’overhead opérationnel de la stack technique
    • Pendant 20 ans, j’ai exploité le SQL auto-hébergé de nombreux clients, et je n’ai jamais vu un serveur SQL tomber
      Le SQL dans le cloud a au contraire une structure de coûts compliquée, et une fois les sauvegardes configurées, il n’y a plus grand-chose à faire

  • Je ne suis pas d’accord avec l’idée que le self-hosting soit le bon choix pour la plupart des gens
    À mon avis, cela n’a de sens que quand le budget est très serré ou quand on a une taille suffisante pour avoir des ingénieurs dédiés
    Pour les petites entreprises, laisser le cloud s’en charger est plus réaliste. Une fois l’installation faite, 30 à 120 minutes de gestion par mois suffisent

    • La plupart des entreprises embauchent quand même des ingénieurs infra même en utilisant le cloud. Dire que « le cloud réduit les coûts humains », c’est faux
      Des PaaS comme Heroku ou Render peuvent être gérés par des développeurs généralistes, mais c’est beaucoup plus cher
      Au final, si la restauration de l’application n’est pas automatisée, on se fait quand même réveiller à 3 h du matin
    • La plupart des services n’ont pas besoin de haute disponibilité. S’ils tombent en panne le samedi, on peut les réparer le lundi
      Pour un outil interne, ajouter un Postgres dans Docker prend 5 minutes
    • Le cloud demande aussi 1 à 2 heures d’administration par mois. La différence avec le self-hosting n’est pas énorme
    • Avec RDS, on perd au contraire en visibilité et en contrôle, ce qui rend le débogage plus difficile
    • La vraie question, ce n’est pas l’efficacité, mais qui se fait engueuler quand ça casse. Avec le cloud, il est plus facile de rejeter la responsabilité

  • La définition de « base de données managée » est floue
    Pour moi, les exigences de base sont les sauvegardes automatiques, l’optimisation des index, le basculement inter-datacenters, la restauration à un instant donné, l’analyse des requêtes lentes et la prévision du stockage
    Si tout cela est fourni dans un abonnement mensuel, le débat sur le self-hosting perd son intérêt

    • Le problème, c’est qu’il faut embaucher des profils spécialisés. Si la personne en charge de Postgres part en vacances, on a un problème de bus factor
      On finit donc par en avoir deux, et comme le travail devient monotone, ils se lancent parfois dans des optimisations inutiles qui font perdre six mois
    • Au final, la raison du self-hosting, c’est la latence. Les sauvegardes ou l’analyse sont la base, mais pour aller le plus vite possible, il faut le construire soi-même
    • Si l’installation est bien faite, les sauvegardes ou le basculement multi-région peuvent aussi être automatisés
    • Je n’auto-héberge que les services qui ne m’appelleront pas à 3 h du matin. Les logs ou l’analytique interne, d’accord, mais jamais une base de données
    • Yugabyte open source couvre la plupart de ces fonctions

  • Les bases de données managées sont beaucoup trop chères par rapport à un VPS
    Je m’attendais à payer une prime pour la commodité, mais en réalité c’est plusieurs fois plus cher. Du coup, je ne les utilise que pour les gros projets

    • On vous fait croire que vous n’êtes pas capable de le faire vous-même, puis les prix augmentent sans cesse. Et comme vous n’avez plus les compétences pour migrer, vous devenez dépendant

  • La partie sur la haute disponibilité (HA) évoquée dans l’article est insuffisante. On ne peut pas l’expliquer avec le seul réglage du WAL. La réplication a un coût important

  • Je ne comprends pas pourquoi Postgres est surévalué sur HN
    Il n’existe pas de moyen simple de mettre en place un cluster HA avec basculement automatique comme avec MongoDB. Je serais curieux de savoir comment les gens gèrent ça en production

    • La communauté PostgreSQL est elle aussi consciente du problème. Elle envie la fiabilité de la réplication intégrée de MongoDB
      Discussion liée : liste de diffusion PostgreSQL
    • Si vous utilisez Kubernetes, CloudNativePG est de fait la solution HA standard
    • Dans le monde SQL, on est habitué non pas à la vraie HA, mais à la reprise rapide après sinistre (Disaster Recovery)
      En pratique, toutes les connexions sautent, les caches sont réinitialisés, et lors des mises à niveau, une interruption de service est inévitable
      Oracle RAC est la seule exception, et PostgreSQL n’est pas conçu ainsi. YugabyteDB est à peu près la seule alternative
      La plupart des applications tolèrent quelques heures d’indisponibilité. Seules les grandes entreprises peuvent absorber une automatisation aussi complexe
    • La méthode la plus courante consiste à utiliser Patroni. Si vous voulez quelque chose de simple, utilisez Autobase
      En environnement Kubernetes, CloudNativePG est aussi un bon choix.
      pg_auto_failover est simple, mais limité
    • En réalité, la plupart des entreprises n’ont pas besoin d’une HA aussi complexe. Le rapport coût/bénéfice est faible

  • En regardant Autobase, on voit qu’il automatise les tâches nécessaires au self-hosting

    • J’ai parcouru le README et il semble que le connection pooling soit hors périmètre
    • Je me demande aussi si cela s’intègre bien avec d’autres PaaS auto-hébergées. On dirait que ça fonctionne sous forme de conteneur Docker
    • Beau projet, merci

  • J’utilise Postgres toujours en self-hosting depuis 15 ans, et je n’ai presque jamais eu de problème
    Mon seul vrai souci, c’était quand il fallait faire une migration de version de PG en phase avec une mise à niveau de l’ORM. Cela se gère avec une administration système prudente

  • J’ai fait tourner moi-même du Postgres non managé sur Fly.io, et ça a été très pénible
    Les nœuds mouraient souvent, et il fallait restaurer manuellement avec repmgr ; j’ai fini par documenter la procédure dans le wiki interne
    Le but d’un cluster est la haute disponibilité, alors je n’ai jamais compris pourquoi il ne gérait pas automatiquement les primaires zombies
    J’ai fini par migrer vers du Postgres managé, et c’est vraiment confortable que quelqu’un d’autre gère les incidents

    • J’utilise maintenant le Managed Postgres de Fly

  • Beaucoup de commentaires dans ce fil ignorent des facteurs très concrets comme l’échelle, la charge de travail, les effectifs, le temps, le stade de l’entreprise et les besoins de montée en charge
    Le self-hosting peut être adapté ou non, mais la discussion est beaucoup trop simpliste

    • Les ingénieurs ont tendance à ne presque jamais prendre ces facteurs en compte et à choisir la solution la plus chère que leur manager approuvera
 
sinbumu 2025-12-22

Pour les développeurs, l’enjeu est sans doute aussi de savoir si ce genre d’éléments sera reconnu lorsqu’on les auto-héberge. Même si les coûts cloud sont plus élevés, si les économies réalisées via l’auto-hébergement ne sont pas prises en compte, il est peut-être plus simple d’utiliser un service cloud et de réduire le périmètre à couvrir.