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

Calcul. Stockage. Rétention de sauvegarde.

L’exportation instantanée que tu as oubliée. Les frais de sortie de l’environnement de préproduction qui a exécuté 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 bon marché.

Mais, zut.

L’écart entre “Postgres pour 25 $ par mois” et ce qui apparaît sur la carte est devenu considérable, et un VPS de 4 GB au prix d’un seul module complémentaire Supabase peut maintenant gérer toute votre base de données avec de l’espace restant pour que le système d’exploitation mette en cache les pages fréquemment consultées.

Auto-héberger une base de données Postgres de production n’est plus le cauchemar opérationnel qu’il était autrefois. Le dépôt PostgreSQL Global Development Group (PGDG) est solide ; les installations modernes de PostgreSQL (v14+) utilisent par défaut le chiffrement de mot de passe SCRAM-SHA-256, avec l’ancien MD5 officiellement déprécié à partir de la v18. Les raisons pour lesquelles les gens restent sur RDS, Supabase ou Neon aujourd’hui sont opérationnelles, pas techniques.

Nous parlons de factures réelles, de coûts opérationnels réels, et à quoi ressemble réellement l’hébergement Postgres moderne.

Quel Est Le Coût Réel Pour Auto-Héberger PostgreSQL Sur Un VPS ?

PostgreSQL auto-hébergé sur un VPS de 4 GB fonctionne généralement à une fraction du coût équivalent de RDS, Supabase Pro, ou Neon Scale une fois que le stockage, les sauvegardes et l’egress sont inclus dans la facturation gérée.

PostgreSQL est la base de données utilisée par 55,6 % des développeurs, selon l’enquête des développeurs 2025 de Stack Overflow, la plus populaire depuis deux ans consécutifs. C’est également la base de données que tu peux gérer toi-même confortablement.

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, région unique), tarifée en mai 2026 :

Option	Calcul	Stockage	Dépassement du forfait gratuit	Idéal pour
Auto-hébergé sur un VPS de 4 GB	Tarif forfaitaire	Généralement inclus	Généralement non mesuré ou à haute capacité	Charges de travail régulières, équipes sensibles aux coûts à l’aise avec Linux
AWS RDS db.t4g.medium	47,45 $/mois uniquement calcul	~0,115 $/GB-mois gp3	~0,09 $/GB internet/hors région	Équipes souhaitant des sauvegardes gérées, basculement et opérations natives AWS
Supabase Pro	25 $/mois de base + utilisation	0,125 $/GB disque base de données au-delà des 8 GB inclus	0,09 $/GB au-delà de 250 GB	Applications nécessitant Postgres, authentification, stockage et temps réel dans une seule pile
Neon Scale	0,222 $ par CU/heure	0,35 $ par GB/mois	Mesuré selon l’utilisation	Workflows de développement avec pics, nombreux aperçus et branches

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

Ajoute 100 Go de stockage gp3 à environ 0,115 $/Go-mois avec des sauvegardes automatisées, et une boîte Single-AZ se situe près de 60 $/mois. Active le basculement Multi-AZ et la ligne de calcul double à peu près, poussant une configuration de grade production à 100 $/mois et plus.

Ce n’est pas un petit écart.

L’auto-hébergement est moins cher parce que tu fais le travail pour lequel la facture gérée était prévue. Discipline des opérations, permanence téléphonique, à 2 heures du matin quand le disque est plein. L’alternative de base de données gérée contre laquelle tu compares pourrait avoir un seuil différent le trimestre prochain, alors fais tes calculs par rapport à ta propre facture avant de t’engager.

Quand Est-Ce Que L’Auto-Hébergement PostgreSQL A-T-Il Du Sens ?

L’auto-hébergement de PostgreSQL sur un VPS est judicieux lorsque tu as une aisance de base avec Linux dans ton équipe, une charge de travail stable, une taille de jeu de travail prévisible, et une vraie raison d’éviter la facture gérée.

Ça ne fonctionne pas lorsque tu n’as aucune capacité opérationnelle, des exigences de HA réglementées que tu ne peux pas construire toi-même, ou un modèle à pics qui bénéficie d’une mise à l’échelle instantanée.

Trois choses motivent cette décision. Le coût, la confidentialité et la souveraineté des données, et le contrôle.

Où l’hébergement autogéré gagne clairement :

• Trafic régulier dans une seule région avec un ensemble de travail prévisible.
• Applications SaaS de petite à moyenne taille avec une base de données Postgres et une équipe à l’aise avec Linux.
• Charges de travail sensibles à la confidentialité où la base de données ne devrait pas être hébergée chez un tiers.
• Équipes soucieuses des coûts dont la facture gérée a dépassé le seuil de complication opérationnelle.

Où la gestion s’impose clairement :

• Charges de travail par à-coups qui bénéficient d’une montée en puissance et d’une réduction instantanées.
• Configurations multi-régions où la réplication mondiale est le produit.
• Environnements réglementés nécessitant des solutions clé en main pour la haute disponibilité, les certificats de conformité et les pistes de vérification.
• Équipes sans capacité opérationnelle disponible et sans plan pour la développer.

Le chiffre d’économies de 40% à 60% est souvent cité. Date-le avec soin.

Depuis 2021, l’auteur de AWS Rupesh Desai a documenté PostgreSQL sur EC2 fonctionnant 40 % à 60 % moins cher que RDS avec des spécifications équivalentes, plus ancien que la plupart des familles d’instances RDS actuelles.

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

Le seuil de rentabilité réel est le nombre d’heures de fonctionnement, et non le coût du serveur.

Comment Choisir La Bonne Taille De VPS Pour PostgreSQL ?

La plupart des bases de données d’applications de production fonctionnent confortablement avec 4 Go de RAM et un stockage NVMe. Les ensembles de données plus importants, les connexions concurrentes lourdes ou les charges de travail analytiques poussent le besoin à 8 Go ou 16 Go et au-delà.

La RAM détermine combien de votre ensemble de travail Postgres peut conserver en mémoire ; une fois que les pages actives sont transférées sur le disque, les requêtes ralentissent. NVMe est important car Postgres est sensible à la latence de lecture aléatoire pour les pages actives et au débit de vidage pour le journal de pré-écriture.

La guidance sur le réglage de PostgreSQL commence 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é de manière conservatrice — basé sur la complexité des requêtes concurrentes, pas seulement sur la RAM totale.

Sur un VPS de 4 Go, cela signifie généralement allouer environ 1 Go à shared_buffers tout en laissant suffisamment de mémoire pour que le cache de pages Linux puisse contenir les données fréquemment accédées. Cet équilibre explique pourquoi une modeste boîte de 4 Go peut confortablement exécuter de nombreuses charges de travail de production de petite à moyenne taille.

La carte du plan à la charge de travail que tu dois connaître :

Niveau de RAM	Charge de travail typique	Plan de pile recommandé
2 GB	Environnements de développement, projets annexes peu fréquentés	En dessous de la base
4 GB	La plupart des bases de données d’applications en production	Pile 4
8 GB	Jeux de données plus grands, plus de connexions simultanées	Pile 8
16 GB+	Postgres à côté d’autres services lourds, analyses	Pile 16

Les plans de VPS Hosting de DreamHost te donnent accès root, un stockage NVMe et une bande passante illimitée avec une facturation 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 ?

Tu installes PostgreSQL sur un VPS en cinq étapes compressées.

1. Configurer le VPS : Choisis un plan avec suffisamment de RAM pour ton ensemble de travail (Stack 4/4 GB est la référence). Ubuntu 24.04 LTS est le système d’exploitation recommandé. Connecte-toi en SSH avec une authentification par clé, pas un mot de passe.
2. Installer depuis le dépôt officiel PGDG : La distribution ‘apt install postgresql’ est en retard de plusieurs versions majeures. Ajoute le dépôt apt de PGDG, puis ‘sudo apt install postgresql-18.’ Confirme avec ‘sudo systemctl status postgresql’
3. Définir le mot de passe postgres et créer ton rôle d’application : Exécute sudo -i -u postgres, puis psql, puis password postgres. Crée un rôle dédié avec le moins de privilèges : ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ et ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Liaison correcte de l’écouteur : Ouvre /etc/postgresql/18/main/postgresql.conf. Définis listen_addresses = ‘localhost’ si l’application et la base de données partagent le serveur, ou lie-toi à une IP privée si l’application fonctionne sur un VPS séparé. Évite de lier PostgreSQL à 0.0.0.0 sur une interface publiquement accessible. Les instances PostgreSQL exposées sont agressivement scannées et forcées par des bots automatisés.
5. Verrouillage de ‘pg_hba.conf’ et UFW : Modifie pg_hba.conf pour permettre seulement les IPs de l’application dont tu as réellement besoin, avec ‘scram-sha-256’ comme méthode d’authentification. Configure UFW pour autoriser le port 5432 uniquement depuis ces mêmes IPs. Utilise un tunnel SSH pour les outils d’administration (et s’il te plaît, n’ouvre pas le 5432 à l’internet public).

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

Un délai d’expiration ou une connexion refusée par une IP non autorisée signifie généralement que ton écouteur et tes règles de pare-feu font leur travail. Une invite de mot de passe provenant de l’internet public signifie que quelque chose est mal configuré. Une fois que Postgres est en fonctionnement, la configuration n’est que la moitié du travail.

Comment Sécuriser PostgreSQL Sur Un VPS ?

PostgreSQL sur un VPS est sécurisé à trois niveaux, en plus de l’hygiène des rôles et de la cadence des correctifs.

1. Authentification : Utilise scram-sha-256 pour les nouvelles installations et retire les règles md5 obsolètes de pg_hba.conf. Les documents de PostgreSQL préviennent désormais que le support des mots de passe cryptés MD5 est déprécié et sera retiré dans une future version.
2. Réseau : Lie PostgreSQL à ‘localhost’, une IP privée, ou une interface accessible uniquement par tes serveurs d’application. Évite de le lier à une interface publiquement accessible. Superpose UFW par-dessus et autorise le port 5432 uniquement depuis les IPs d’application de confiance.
3. Chiffrement en transit : Active le TLS pour toute connexion traversant une limite de réseau. Définis ssl = on dans postgresql.conf, puis utilise les règles hostssl … scram-sha-256 dans pg_hba.conf afin que les clients ne puissent pas basculer silencieusement vers des connexions non-TLS. Les certificats auto-signés sont acceptables pour le trafic interne si les clients les vérifient correctement.
4. Rôles : Les connexions d’application doivent utiliser un rôle de moindre privilège avec uniquement les droits nécessaires pour les schémas de cette application. Le superutilisateur est pour les migrations et les urgences.
5. Mises à jour : Utilise le dépôt apt PGDG pour les paquets PostgreSQL actuels. Active les mises à jour de sécurité non surveillées pour l’OS, mais planifie délibérément les mises à jour de PostgreSQL afin qu’un redémarrage inattendu ne devienne pas ton incident de la semaine. 

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

• Utilise uniquement scram-sha-256 ; désactive md5.
• Lie les ‘listen_addresses’ à localhost ou à une IP privée.
• Les règles UFW autorisent 5432 uniquement depuis des IPs de confiance.
• SSL/TLS activé pour toute connexion traversant un réseau.
• L’application se connecte avec un rôle aux privilèges minimaux, jamais en tant que ‘postgres’.
• Mises à jour de sécurité non assistées activées.
• Aucune ligne ‘host all all 0.0.0.0/0 md5’ nulle part dans ‘pg_hba.conf’, jamais.

Cette dernière puce est la mise en garde.

Le port accessible au public 5432 avec des identifiants faibles est une cible connue de cryptominage et d’attaques par force brute. Les instances PostgreSQL exposées sont constamment scannées par des robots automatisés à la recherche de comptes par défaut, de mots de passe divulgués, ou de règles permissives de pg_hba.conf.

Les instances Postgres accessibles publiquement avec une authentification faible sont souvent compromises de manière choquante et rapide. Une base de données directement exposée à internet sans contrôles de réseau appropriés, TLS et isolation des rôles est le type d’erreur qui se transforme en rapport d’incident. Une base de données correctement configurée n’est qu’à une panne de disque de la perte de données.

Comment Sauvegarder Et Répliquer PostgreSQL Sur Un VPS ?

Les sauvegardes PostgreSQL sur un VPS utilisent l’un des trois mécanismes, choisi en fonction de la panne que tu cherches à prévenir. Les sauvegardes logiques via pg_dump pour la portabilité, les sauvegardes physiques via pg_basebackup plus l’archivage WAL pour la récupération à un point donné, et la réplication en continu pour une haute disponibilité.

Les sauvegardes logiques gèrent les migrations, les restaurations partielles et les rafraîchissements de dev. Exécute pg_dump –format=custom –file=mydb.dump mydb_prod depuis un Cron Job quotidien. Le format personnalisé compresse bien et, avec le format de répertoire, supporte les options de restauration parallèle et sélective de pg_restore. Poussez le dump vers un Object Storage hors-VPS (DreamObjects, compatible S3).

Les sauvegardes physiques permettent des restaurations complètes du système et des récupérations à un moment précis. pg_basebackup plus l’archivage continu du journal de validation anticipée (WAL) te permet de récupérer à tout moment entre la dernière sauvegarde de base et le segment WAL le plus récent, l’option de niveau production lorsque la tolérance à la perte de données se compte en secondes, et non en heures.

La réplication en streaming est la troisième option. Une réplique en lecture sur un second VPS est une sauvegarde à chaud pour les charges de travail intensives en lecture ou une cible de basculement rapide. La configuration de réplication de la base de données coûte un second VPS mais limite votre pire interruption à quelques minutes.

Mécanisme	Ce Qu’il T’offre	Ce Qu’il Coûte
pg_dump + cron + stockage hors-VPS	Sauvegarde logique quotidienne, portable	Latence de restauration, pas de restauration à l’instant T
pg_basebackup + archivage WAL	Sauvegarde physique avec récupération à l’instant T	Complexité opérationnelle et de stockage
Réplication en continu	Support actif, objectif de point de récupération (RPO) proche de zéro, échelonnage en lecture	Second VPS plus gestion de la réplication

Restauration-test mensuelle. Les services gérés intègrent tout cela, et c’est une partie de ce que les économies d’auto-hébergement permettent de récupérer. Si tu es déjà chez un fournisseur géré, le chemin pour en sortir est plus simple qu’il n’y paraît.

Comment Migrer De RDS, Supabase Ou Neon Vers Un VPS ?

Tu migres d’un fournisseur Postgres géré à un VPS en quatre étapes.

1. Préparer le VPS cible : Assortir exactement à la version majeure de Postgres source. Installe PostgreSQL sur le nouveau VPS en suivant les étapes ci-dessus, puis crée préalablement le rôle d’application et la base de données.
2. Extraction depuis la source : Exécute pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Les drapeaux –no-owner et –no-privileges retirent les attributions de rôles spécifiques au fournisseur qui se recréent rarement proprement sur un nouvel hôte.
3. Restaurer vers la cible : Exécute pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Sois attentif aux avertissements d’extensions. RDS, Supabase et Neon activent souvent des extensions qui peuvent ne pas exister sur un Postgres vanille. Installe des extensions compatibles à partir des paquets PGDG ou postgresql-contrib avant de restaurer.
4. Échange et vérification de la chaîne de connexion : Oriente d’abord un environnement de préproduction vers le nouveau VPS, exécute ta suite de tests, puis valide les requêtes de production représentatives et les flux d’application avant de changer la chaîne de connexion de production. Pour les applications à faible écriture, une courte fenêtre de maintenance lors du basculement final est souvent plus simple que la mise en place de la réplication. Conserve la base de données source en ligne et en lecture seule pendant plusieurs jours comme cible de retour en arrière.

Quels changements par fournisseur ?

1. Depuis RDS : Les rôles spécifiques à RDS (‘rds_superuser,’ ‘rdsadmin’) n’existent pas dans Postgres standard ; –no-owner et –no-privileges gèrent la plupart de ces aspects. Certaines extensions gérées par RDS nécessitent une installation manuelle, et la sortie d’AWS pendant la sauvegarde est facturable.
2. Depuis Supabase : Le Postgres de Supabase est un vrai Postgres, mais les couches d’authentification, de stockage et de périphérie de Supabase ne migrent pas. Le schéma de ton application, lui, migre. Remplace ces couches par des équivalents auto-hébergés avant de basculer.
3. Depuis Neon : Le branchement disparaît après la migration ; prévois des sauvegardes à la place. La restauration par dump est simple, mais les habitudes opérationnelles comme les branches instantanées nécessitent un workflow de remplacement.

La migration elle-même prend généralement moins de temps que de choisir le plan VPS. Le temps d’arrêt réaliste est de quelques minutes pour les petites bases de données, plus long avec la relecture WAL pour les grandes. La plupart des installations s’arrêtent ici, mais il y a un scénario qui te pousse plus loin…

Quand Devrais-Tu Ajouter PgBouncer ou Rester Avec Vanilla Postgres ?

La plupart des applications sur un VPS de 4 GB n’ont pas besoin d’un pool de connexions au début. Ajoute PgBouncer lorsque les connexions simultanées dépassent environ 100, ou lorsque ta pile d’applications ouvre une nouvelle connexion par requête.

Les connexions PostgreSQL sont lourdes car chacune représente un processus complet du système d’exploitation. Avec 4 Go de RAM, tu ne veux pas de centaines de connexions inactives consommant de la mémoire. Le pooler conserve les connexions Postgres coûteuses de son côté et distribue des connexions bon marché et éphémères à ton application de l’autre.

Deux modes de regroupement importent :

• Groupement de sessions : Chaque client obtient une connexion serveur pour la session. Sécurisé pour toute application, aucun changement de sémantique, gain de débit plus faible.
• Groupement de transactions : Chaque client obtient une connexion serveur pour une transaction. Grand gain de débit. Vous perdez des fonctionnalités reposant sur l’état de la session (déclarations préparées, verrous consultatifs, ‘LISTEN’/’NOTIFY’) à moins que l’application ne soit écrite pour s’y attendre.

La plupart des petites applications SaaS avec un ORM utilisant un pool de connexions se débrouillent bien sans PgBouncer jusqu’à ce qu’elles ne le fassent plus. Le signal que tu as franchi la limite est les erreurs ‘FATAL: too many connections’ ou la pression sur la mémoire due aux connexions inactives.

Installe-le avec sudo apt install pgbouncer, configure /etc/pgbouncer/pgbouncer.ini avec ta liste de bases de données et le mode pool, puis dirige l’application vers PgBouncer sur le port 6432.

Oui, tu sauras quand tu en auras besoin.

Prendre La Décision Finale

L’écart de coût est suffisamment réel pour justifier le calcul par rapport à ta propre facture. Mais la configuration n’est pas la partie difficile.

La partie difficile est le travail opérationnel que la facture gérée payait. Sauvegardes, exercices de restauration, patchs et surveillance.

De toute façon, prends une grande respiration avant d’ouvrir ta prochaine facture.

Questions Fréquemment Posées Sur PostgreSQL Sur Un VPS

Combien de RAM PostgreSQL nécessite-t-il sur un VPS ?

PostgreSQL fonctionne sur 1 à 2 Go pour de petites charges de travail et confortablement sur 4 Go pour la plupart des bases de données d’applications de production. Des ensembles de données plus lourds, plus de connexions simultanées ou des charges de travail analytiques poussent le besoin à 8 Go ou plus.

Puis-je exécuter PostgreSQL sur un VPS de 2 GB ?

Oui, tu peux exécuter PostgreSQL sur un VPS de 2 GB pour des petites applications, des environnements de développement et des projets annexes à faible trafic. Une boîte de 2 GB laisse peu de marge pour la mise en cache, donc les performances des requêtes diminuent à mesure que tes données dépassent la mémoire. Pour les charges de travail en production, 4 GB est la base plus sûre.

L’auto-hébergement de PostgreSQL sur un VPS est-il moins cher que RDS ou Supabase ?

Oui, l’auto-hébergement de PostgreSQL sur un VPS est moins cher que RDS ou Supabase pour la plupart des charges de travail en état stable. Un VPS de 4 Go fonctionne généralement pour une fraction du coût équivalent à RDS, Supabase Pro, ou Neon Scale une fois que le stockage, les sauvegardes et le transfert sortant sont pris en compte. Le compromis est que tu opères la base de données toi-même.

Comment exposer PostgreSQL sur un VPS de manière sécurisée ?

Ne pas exposer le port 5432 à l’internet public. Lie PostgreSQL à localhost ou une IP privée, exige une authentification scram-sha-256, et utilise un tunnel SSH pour les outils d’administration au lieu d’ouvrir le 5432 à ton ordinateur portable. Un 5432 public avec une authentification faible est une cible connue pour les cryptomineurs.

Ai-je besoin d’utiliser Docker pour PostgreSQL sur un VPS ?

Non, Docker n’est pas nécessaire. Le dépôt apt officiel de PGDG installe PostgreSQL en tant que service système natif, ce qui est la configuration la plus simple pour une production. Docker est raisonnable si tu utilises déjà d’autres conteneurs.

Comment sauvegarder PostgreSQL sur un VPS ?

Exécute pg_dump –format=custom sur un planning Cron quotidien et stocke le résultat sur un stockage objet compatible S3 en dehors du VPS. Utilise pg_basebackup plus l’archivage WAL pour une récupération à un moment précis lorsque quelques secondes de perte de données sont importantes. Test de restauration mensuel.

Quel plan devrais-je choisir pour l’auto-hébergement de PostgreSQL sur DreamHost ?

Le plan VPS Stack 4 de DreamHost (4 GB RAM) est la base recommandée pour la plupart des bases de données d’applications de production. Choisis Stack 8 (8 GB) pour des ensembles de données plus larges ou une haute concurrence, et Stack 16 pour Postgres aux côtés d’autres services gourmands en ressources.

Devrais-je utiliser PgBouncer avec PostgreSQL sur un petit VPS ?

La plupart des applications sur un VPS de 4 Go n’ont pas besoin de PgBouncer au début. Ajoute un gestionnaire de pool de connexions lorsque les connexions simultanées approchent 100, ou lorsque ton application ouvre une nouvelle connexion par requête.