Pourquoi auto-héberger PostgreSQL sur un VPS
Les bases managées (RDS, Cloud SQL) facturent au Go stocké, aux IOPS et aux connexions, et limitent souvent les extensions disponibles. En déployant PostgreSQL sur votre propre VPS, vous activez pg_stat_statements, PostGIS, pgvector ou TimescaleDB sans restriction, vous choisissez votre version exacte (15, 16, 17) et vous gardez vos données dans une juridiction que vous maîtrisez. Un VPS avec disque SSD offre des latences I/O très basses, idéales pour les workloads transactionnels d'une application en production. Vous payez un forfait fixe et prévisible, et vous décidez seul de votre stratégie de réplication, de chiffrement et de rétention des backups.
Les bénéfices concrets d'un PostgreSQL auto-hébergé
- Coût fixe et prévisible : pas de facturation au Go, aux IOPS ni au nombre de connexions actives.
- Extensions libres :
pgvectorpour l'IA,PostGISpour le géospatial,TimescaleDBpour les séries temporelles. - Contrôle total des sauvegardes :
pg_dumpplanifié,pg_basebackupou réplication physique vers un second VPS. - Tuning fin de
postgresql.conf(shared_buffers, work_mem, WAL) impossible chez la plupart des offres managées. - Souveraineté des données : vos données restent sur une infrastructure que vous choisissez.
- Accès superutilisateur réel pour auditer, profiler et optimiser sans ticket support.
Prérequis matériels et logiciels
Pour une instance PostgreSQL de développement ou un petit projet en production, prévoyez un VPS avec 2 vCPU, 4 Go de RAM et 40 Go de SSD NVMe : PostgreSQL aime la mémoire pour son cache de pages. Pour une charge plus soutenue (plusieurs centaines de connexions ou jeux de données de plusieurs dizaines de Go), visez 4 vCPU et 8 Go de RAM. Côté logiciel : Ubuntu 22.04 ou 24.04 LTS, Docker Engine et le plugin Docker Compose v2, un nom de domaine pointant vers le VPS (ex : db.mondomaine.com) si vous exposez l'accès distant, et un pare-feu ufw configuré pour ne laisser passer que le strict nécessaire. Réservez aussi un volume Docker dédié pour PGDATA afin de découpler les données du conteneur.
Déployer PostgreSQL avec Docker en production
Préparer le VPS et le pare-feu
Connectez-vous en SSH, mettez à jour le système avec
apt update && apt upgrade -y, installez Docker viacurl -fsSL https://get.docker.com | sh. Bloquez le port 5432 depuis l'extérieur avecufw deny 5432: la base ne doit jamais être directement exposée à Internet.Écrire le docker-compose.yml
Créez un service
postgres:17, montez un volume nommé sur/var/lib/postgresql/data, et définissezPOSTGRES_PASSWORD,POSTGRES_DBetPOSTGRES_USERvia un fichier.envjamais commité. Ajoutezshm_size: 256mbpour les tris volumineux et unehealthcheckavecpg_isready.Lancer et initialiser la base
Démarrez avec
docker compose up -d, vérifiez les logs viadocker compose logs -f postgres, puis connectez-vous avecdocker compose exec postgres psql -U app -d mabase. Créez vos rôles applicatifs avec des privilèges minimaux plutôt que d'utiliser le superutilisateur.Exposer l'accès via un tunnel ou un proxy TLS
Pour un accès distant sécurisé, n'ouvrez jamais 5432 en clair : utilisez un tunnel SSH (
ssh -L 5432:localhost:5432) ou placezpgbouncerderrière un reverse proxy. Activez le SSL côté PostgreSQL avec un certificat Let's Encrypt monté dans le conteneur (ssl = ondanspostgresql.conf).Tuner la configuration
Ajustez
shared_buffersà environ 25% de la RAM,effective_cache_sizeà 50-75%, etwork_memselon vos requêtes. Activezpg_stat_statementspour identifier les requêtes lentes. Utilisez l'outil PGTune comme point de départ.Automatiser les sauvegardes
Planifiez un
pg_dumpquotidien via une tâche cron sur l'hôte, compressez en.dumpcustom format, et copiez les archives vers un stockage externe. Testez régulièrement la restauration avecpg_restore: une sauvegarde non testée n'existe pas.Se connecter la première fois
pgAdmin n'est pas publié sur Internet : ouvrez un tunnel depuis votre poste (ssh -L 5050:127.0.0.1:5050 root@<IP>) puis http://127.0.0.1:5050, et connectez-vous avec [email protected] et le mot de passe fourni. Ajoutez ensuite votre serveur (« Add New Server ») avec l'hôte db, le port 5432, l'utilisateur postgres et ce même mot de passe.
Pour une haute disponibilité, déployez un second VPS en réplication physique en streaming (primary_conninfo + slot de réplication). Vous obtenez une standby chaude prête à basculer, et vous pouvez y déporter vos requêtes de lecture lourdes (hot_standby = on) pour soulager le primaire. Couplé à pgBackRest pour des backups incrémentaux différentiels, vous atteignez un RPO de quelques minutes sans dépendre d'un service managé.
La documentation officielle
Pour la configuration avancée, les options propres à l’outil et les changements de version, référez-vous à la documentation officielle de PostgreSQL. Ce guide couvre la mise en ligne sur VPS ServOrbit ; la documentation éditeur reste la référence pour les réglages fins.
