PostgreSQL auto-hébergé sur un VPS : échappez aux tarifs des bases de données gérées

Calcul. Stockage. Conservation des sauvegardes.

L'export de snapshot que vous aviez oublié. Les frais de trafic sortant de l'environnement de préproduction qui a lancé un ‘pg_dump’ mardi dernier.

Personne n'ouvre sa facture de base de données gérée en s'attendant à ce qu'elle soit modique.

Mais quand même.

L'écart entre Postgres à 25 $ par mois et le montant débité sur votre carte s'est creusé. Aujourd'hui, un VPS de 4 Go au prix d'une seule option Supabase fait tourner toute votre base de données, avec assez de marge pour que le système d'exploitation mette en cache les pages chaudes.

Auto-héberger une base Postgres de production n'est plus le cauchemar opérationnel d'autrefois. Le dépôt du PostgreSQL Global Development Group (PGDG) est fiable. Les installations modernes de PostgreSQL (v14+) utilisent par défaut le chiffrement de mots de passe SCRAM-SHA-256, et l'ancien MD5 est officiellement déprécié depuis la v18. Si l'on reste aujourd'hui sur RDS, Supabase ou Neon, c'est pour des raisons opérationnelles, pas techniques.

Nous parlons ici de vraies factures, d'une vraie charge opérationnelle et de ce à quoi ressemble réellement l'hébergement Postgres moderne.

Combien coûte vraiment l'auto-hébergement de PostgreSQL sur un VPS ?

PostgreSQL auto-hébergé sur un VPS de 4 Go coûte généralement une fraction du prix équivalent chez RDS, Supabase Pro ou Neon Scale, une fois que le stockage, les sauvegardes et le trafic sortant s'ajoutent à la facture du service géré.

PostgreSQL est la base de données utilisée par 55,6 % des développeurs, selon le Developer Survey 2025 de Stack Overflow, et la plus populaire depuis deux années consécutives. C'est aussi une base de données que vous pouvez sans difficulté gérer vous-même.

Comparaison pour une charge de travail représentative d'une petite équipe (4 Go de RAM, ~100 Go de données, charge d'écriture faible à modérée, une seule région), aux tarifs de mai 2026 :

Le tarif à la demande de RDS db.t4g.medium est d'environ 0,065 $ de l'heure, soit environ 47,45 $ par mois pour le calcul seul.

Ajoutez 100 Go de stockage gp3 à environ 0,115 $/Go-mois et les sauvegardes automatisées, et une instance Single-AZ approche les 60 $/mois. Activez le basculement Multi-AZ et la ligne « calcul » double à peu près, ce qui porte une configuration de niveau production à 100 $/mois et plus.

Ce n'est pas un petit écart.

L'auto-hébergement coûte moins cher parce que c'est vous qui faites le travail que payait la facture du service géré : discipline opérationnelle, astreintes, intervention à 2 h du matin quand le disque est plein. L'alternative gérée à laquelle vous vous comparez aura peut-être un autre prix plancher le trimestre prochain. Faites donc le calcul avec votre propre facture avant de vous engager.

Quand l'auto-hébergement de PostgreSQL est-il pertinent ?

Auto-héberger PostgreSQL sur un VPS a du sens lorsque votre équipe maîtrise les bases de Linux, que votre charge de travail est stable, que la taille de votre jeu de données actif est prévisible et que vous avez une vraie raison d'échapper à la facture du service géré.

Cela ne fonctionne pas si vous n'avez aucune capacité d'exploitation, si vous avez des exigences réglementaires de haute disponibilité (HA) que vous ne pouvez pas mettre en place vous-même, ou si votre trafic connaît des pics qui profitent d'une mise à l'échelle instantanée.

Trois facteurs guident cette décision : le coût, la confidentialité et la souveraineté des données, et le contrôle.

Là où l'auto-hébergement l'emporte nettement :

• Trafic stable dans une seule région, avec un jeu de données actif prévisible.
• Applications SaaS de petite ou moyenne taille avec une seule base Postgres et une équipe à l'aise avec Linux.
• Charges de travail sensibles en matière de confidentialité, où la base de données ne doit pas résider dans l'infrastructure d'un tiers.
• Équipes soucieuses des coûts dont la facture de service géré a fini par dépasser le coût des contraintes opérationnelles.

Là où le service géré l'emporte nettement :

• Charges en pics qui profitent d'une mise à l'échelle instantanée, à la hausse comme à la baisse.
• Configurations multirégions où la réplication mondiale est au cœur du produit.
• Environnements réglementés nécessitant une HA clé en main, des certifications de conformité et des pistes d'audit.
• Équipes sans capacité d'exploitation disponible ni projet d'en développer.

Le chiffre de 40 à 60 % d'économies est souvent cité. Vérifiez bien sa date.

En 2021, Rupesh Desai, auteur chez AWS, a montré que PostgreSQL sur EC2 coûtait 40 à 60 % moins cher que RDS à caractéristiques équivalentes. Cette étude est antérieure à la plupart des familles d'instances RDS actuelles.

La version actuelle est l'analyse des coûts de byteiota, publiée fin 2025, selon laquelle RDS est 75 à 88 % plus cher que du matériel dédié équivalent.

Le vrai seuil de rentabilité se mesure en heures d'exploitation, pas en coût de serveur.

Comment choisir la bonne taille de VPS pour PostgreSQL ?

La plupart des bases de données d'applications en production tournent sans difficulté avec 4 Go de RAM et un stockage NVMe. Des jeux de données plus volumineux, de nombreuses connexions simultanées ou des charges analytiques font passer le besoin à 8 Go, voire 16 Go et plus.

La RAM détermine la part de votre jeu de données actif que Postgres peut garder en mémoire. Dès que les pages chaudes débordent sur le disque, les requêtes ralentissent. Le NVMe compte, car Postgres est sensible à la latence des lectures aléatoires pour les pages chaudes et au débit d'écriture du journal d'écriture anticipée (WAL).

Les recommandations courantes d'optimisation de PostgreSQL commencent par :

• shared_buffers à environ 25 % de la RAM du système.
• effective_cache_size à environ 50 à 75 % de la RAM du système.
• work_mem dimensionné prudemment, selon la complexité des requêtes simultanées et pas seulement selon la RAM totale.

Sur un VPS de 4 Go, cela revient généralement à allouer environ 1 Go à shared_buffers, tout en laissant assez de mémoire au cache de pages de Linux pour conserver les données fréquemment consultées. Cet équilibre explique en partie pourquoi une modeste machine de 4 Go peut faire tourner sans difficulté de nombreuses charges de production de petite à moyenne taille.

La correspondance entre offres et charges de travail à connaître :

Les offres d'hébergement VPS de DreamHost vous donnent un accès root, un stockage NVMe et une bande passante illimitée, avec une facture mensuelle prévisible.

Ce sont les quatre éléments dont dépend une charge de travail Postgres auto-hébergée.

Comment installer PostgreSQL sur un VPS ?

Vous installez PostgreSQL sur un VPS en cinq étapes condensées.

1. Provisionnez le VPS : choisissez une offre avec assez de RAM pour votre jeu de données actif (Stack 8/8 Go pour la production). Ubuntu 24.04 LTS est le système d'exploitation recommandé. Connectez-vous en SSH avec une authentification par clé, pas par mot de passe.
2. Installez depuis le dépôt officiel PGDG : la commande ‘apt install postgresql’ de la distribution a du retard sur les versions majeures. Ajoutez le dépôt apt PGDG, puis ‘sudo apt install postgresql-18.’ Vérifiez avec ‘sudo systemctl status postgresql’
3. Définissez le mot de passe postgres et créez le rôle de votre application : exécutez sudo -i -u postgres, puis psql, puis password postgres. Créez un rôle dédié à privilèges minimaux : ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ et ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Configurez correctement l'écoute : ouvrez /etc/postgresql/18/main/postgresql.conf. Définissez listen_addresses = ‘localhost’ si l'application et la base de données partagent la même machine, ou liez l'écoute à une IP privée si l'application tourne sur un VPS séparé. Évitez de lier PostgreSQL à 0.0.0.0 sur une interface accessible publiquement. Les instances PostgreSQL exposées sont activement scannées et attaquées par force brute par des bots automatisés.
5. Verrouillez ‘pg_hba.conf’ et UFW : modifiez pg_hba.conf pour n'autoriser que les IP d'application dont vous avez réellement besoin, avec ‘scram-sha-256’ comme méthode d'authentification. Configurez UFW pour n'autoriser le port 5432 que depuis ces mêmes IP. Passez par un tunnel SSH pour les outils d'administration (et, s'il vous plaît, n'ouvrez pas le port 5432 sur l'Internet public).

Testez depuis une autre machine : psql -h <vps-ip> -U postgres.

Un délai d'expiration ou une connexion refusée depuis une IP non autorisée signifie généralement que vos règles d'écoute et de pare-feu font leur travail. Une invite de mot de passe depuis l'Internet public signifie qu'il y a une erreur de configuration. Une fois Postgres lancé, la configuration n'est que la moitié du travail.

Comment sécuriser PostgreSQL sur un VPS ?

PostgreSQL sur un VPS se sécurise à trois niveaux, auxquels s'ajoutent une bonne hygiène des rôles et des mises à jour régulières.

1. Authentification : utilisez scram-sha-256 pour les nouvelles installations et supprimez les anciennes règles md5 de pg_hba.conf. La documentation de PostgreSQL avertit désormais que la prise en charge des mots de passe chiffrés en MD5 est dépréciée et sera supprimée dans une future version.
2. Réseau : liez PostgreSQL à ‘localhost’, à une IP privée ou à une interface accessible uniquement par vos serveurs d'applications. Évitez de le lier à une interface accessible publiquement. Ajoutez UFW par-dessus et n'autorisez le port 5432 que depuis des IP d'application de confiance.
3. Chiffrement en transit : activez TLS pour toute connexion qui franchit une frontière réseau. Définissez ssl = on dans postgresql.conf, puis utilisez des règles hostssl … scram-sha-256 dans pg_hba.conf pour que les clients ne puissent pas basculer discrètement vers des connexions sans TLS. Les certificats autosignés sont acceptables pour le trafic interne si les clients les vérifient correctement.
4. Rôles : les connexions de l'application doivent utiliser un rôle à privilèges minimaux, avec uniquement les droits nécessaires sur les schémas de cette application. Le superutilisateur est réservé aux migrations et aux urgences.
5. Mises à jour : utilisez le dépôt apt PGDG pour obtenir des paquets PostgreSQL à jour. Activez les mises à jour de sécurité automatiques pour le système d'exploitation, mais planifiez délibérément les mises à jour de PostgreSQL pour qu'un redémarrage inattendu ne devienne pas l'incident de la semaine.

Votre liste de contrôle de sécurité :

• Utilisez uniquement scram-sha-256 ; désactivez md5.
• Liez ‘listen_addresses’ à localhost ou à une IP privée.
• Les règles UFW n'autorisent le port 5432 que depuis des IP de confiance.
• SSL/TLS activé pour toute connexion qui traverse le réseau.
• L'application se connecte avec un rôle à privilèges minimaux, jamais en tant que ‘postgres’.
• Mises à jour de sécurité automatiques activées.
• Aucune ligne ‘host all all 0.0.0.0/0 md5’ dans ‘pg_hba.conf’, jamais.

Ce dernier point mérite une vraie mise en garde.

Un port 5432 exposé publiquement avec des identifiants faibles est une cible connue des cryptomineurs et des attaques par force brute. Les instances PostgreSQL exposées sont scannées en continu par des bots automatisés à la recherche de comptes par défaut, de mots de passe divulgués ou de règles pg_hba.conf trop permissives.

Les instances Postgres accessibles publiquement et protégées par une authentification faible sont souvent compromises à une vitesse effarante. Une base de données exposée directement sur Internet sans contrôles réseau adéquats, sans TLS ni isolation des rôles, c'est le genre d'erreur qui finit en rapport d'incident. Et même une base de données correctement configurée n'est qu'à une panne de disque d'une perte de données.

Comment sauvegarder et répliquer PostgreSQL sur un VPS ?

Les sauvegardes PostgreSQL sur un VPS reposent sur l'un de trois mécanismes, choisi selon la défaillance contre laquelle vous vous protégez : des sauvegardes logiques via pg_dump pour la portabilité, des sauvegardes physiques via pg_basebackup avec archivage des WAL pour la restauration à un instant donné, et la réplication en continu pour la haute disponibilité.

Les sauvegardes logiques servent aux migrations, aux restaurations partielles et au rafraîchissement des environnements de développement. Exécutez pg_dump –format=custom –file=mydb.dump mydb_prod depuis un Cron Job quotidien. Le format custom se compresse bien et, comme le format directory, prend en charge les options de restauration parallèle et sélective de pg_restore. Envoyez le dump vers un stockage objet compatible S3, hors du VPS.

Les sauvegardes physiques servent aux restaurations complètes du système et à la restauration à un instant donné. pg_basebackup, associé à l'archivage continu du journal d'écriture anticipée (WAL), vous permet de restaurer n'importe quel moment entre la dernière sauvegarde de base et le segment WAL le plus récent. C'est l'option de niveau production lorsque la tolérance à la perte de données se compte en secondes, pas en heures.

La réplication en continu est la troisième option. Un réplica en lecture sur un second VPS sert de serveur de secours à chaud pour les charges à forte lecture ou de cible de basculement rapide. Cette configuration de réplication coûte un second VPS, mais limite votre pire panne à quelques minutes.

Testez la restauration chaque mois. Les services gérés intègrent tout cela d'office, et c'est en partie là que se trouvent les économies de l'auto-hébergement. Si vous utilisez déjà un fournisseur géré, en sortir est plus simple qu'il n'y paraît.

Comment migrer de RDS, Supabase ou Neon vers un VPS ?

La migration d'un fournisseur Postgres géré vers un VPS se fait en quatre étapes.

1. Provisionnez le VPS cible : utilisez exactement la même version majeure de Postgres que la source. Installez PostgreSQL sur le nouveau VPS en suivant les étapes ci-dessus, puis créez à l'avance le rôle et la base de données de l'application.
2. Faites un dump de la source : exécutez pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Les options –no-owner et –no-privileges suppriment les attributions de rôles propres au fournisseur, qui se recréent rarement proprement sur un nouvel hôte.
3. Restaurez sur la cible : exécutez pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Surveillez les avertissements liés aux extensions. RDS, Supabase et Neon activent souvent des extensions qui peuvent ne pas exister dans un Postgres standard. Installez des extensions compatibles depuis les paquets PGDG ou postgresql-contrib avant la restauration.
4. Changement de chaîne de connexion et vérification : pointez d'abord un environnement de préproduction vers le nouveau VPS, lancez votre suite de tests, puis validez des requêtes de production et des parcours applicatifs représentatifs avant de modifier la chaîne de connexion de production. Pour les applications qui écrivent peu, une courte fenêtre de maintenance lors de la bascule finale est souvent plus simple que la mise en place d'une réplication. Gardez la base source en ligne et en lecture seule pendant plusieurs jours pour pouvoir revenir en arrière.

Qu'est-ce qui change selon le fournisseur ?

1. Depuis RDS : les rôles propres à RDS (« rds_superuser », « rdsadmin ») n'existent pas dans un Postgres standard ; –no-owner et –no-privileges règlent l'essentiel du problème. Certaines extensions gérées par RDS doivent être installées manuellement, et le trafic sortant d'AWS pendant le dump est facturé.
2. Depuis Supabase : le Postgres de Supabase est un vrai Postgres, mais ses couches d'authentification, de stockage et edge ne migrent pas. Le schéma de votre application, si. Remplacez ces couches par des équivalents auto-hébergés avant la bascule.
3. Depuis Neon : la création de branches disparaît après la migration ; prévoyez plutôt des sauvegardes. Le dump et la restauration sont simples, mais des habitudes comme les branches instantanées exigent un autre flux de travail.

La migration elle-même prend généralement moins de temps que le choix du forfait VPS. Comptez quelques minutes d'interruption pour les petites bases de données, davantage pour les grandes avec la relecture des WAL. La plupart des installations s'arrêtent là, mais un scénario peut vous pousser plus loin…

Quand ajouter PgBouncer et quand s'en tenir à Postgres standard ?

La plupart des applications sur un VPS de 4 Go n'ont pas besoin d'un gestionnaire de pool de connexions au départ. Ajoutez PgBouncer lorsque les connexions simultanées dépassent environ 100, ou si votre stack applicative ouvre une nouvelle connexion par requête.

Les connexions PostgreSQL sont lourdes, car chacune correspond à un processus complet du système d'exploitation. Avec 4 Go de RAM, vous ne voulez pas que des centaines de connexions inactives dévorent la mémoire. Le gestionnaire de pool conserve de son côté les coûteuses connexions Postgres et distribue de l'autre des connexions légères et éphémères à votre application.

Deux modes de mise en pool comptent :

• Mise en pool par session : chaque client obtient une connexion serveur pour toute la session. Sans risque pour n'importe quelle application, aucun changement de sémantique, mais un gain de débit plus faible.
• Mise en pool par transaction : chaque client obtient une connexion serveur le temps d'une transaction. Gros gain de débit. Vous perdez les fonctionnalités qui reposent sur l'état de session (requêtes préparées, verrous consultatifs, LISTEN/NOTIFY), sauf si l'application est conçue pour s'en passer.

La plupart des petites applications SaaS dotées d'un ORM avec pool de connexions se passent très bien de PgBouncer… jusqu'au jour où ce n'est plus le cas. Le signal que vous avez franchi le cap : des erreurs « FATAL: too many connections » ou une pression mémoire due aux connexions inactives.

Installez-le avec sudo apt install pgbouncer, configurez /etc/pgbouncer/pgbouncer.ini avec votre liste de bases de données et le mode de pool, puis pointez l'application vers PgBouncer sur le port 6432.

Rassurez-vous, vous saurez quand vous en aurez besoin.

Prendre la décision finale

L'écart de coût est assez réel pour justifier de faire le calcul avec votre propre facture. Mais l'installation n'est pas le plus difficile.

Le plus difficile, c'est le travail opérationnel que payait la facture du service géré : sauvegardes, exercices de restauration, mises à jour et surveillance.

Dans tous les cas, respirez un bon coup avant d'ouvrir votre prochaine facture.

Questions fréquentes sur PostgreSQL sur un VPS