Comment deployer une base de donnees PostgreSQL en production sur un VPS en 7 etapes

Deployer PostgreSQL en production sur un VPS est un passage oblige pour tout developpeur open source qui veut depasser le stade du prototype. Que vous construisiez une application SaaS, une API backend, un site e-commerce ou une plateforme de donnees, PostgreSQL est le choix de reference — et son deploiement en production sur un VPS reste la solution la plus flexible et la plus economique pour les startups et les PME francaises.

Pourtant, la distance entre un PostgreSQL fonctionnel en developpement local et un PostgreSQL robuste en production est considerable. En local, vous acceptez les connexions sans mot de passe, vous ne vous souciez pas des sauvegardes, vous ne monitorez rien, et les performances par defaut sont suffisantes pour vos 1 000 lignes de test. En production, chacun de ces raccourcis devient une bombe a retardement.

Ce guide detaille les 7 etapes concretes pour passer d’un PostgreSQL de developpement a un PostgreSQL de production solide, securise et supervisable. Chaque etape inclut les commandes exactes, les fichiers de configuration et les explications du « pourquoi » derriere chaque choix. Si vous utilisez Docker, notre guide complementaire sur le deploiement Docker en production securisee couvre les specificites de la conteneurisation. Et avec l’arrivee de PostgreSQL 19 en septembre 2026, c’est le moment ideal pour poser des bases solides.

Etape 1 : Installer PostgreSQL depuis le depot officiel

Ne jamais utiliser la version PostgreSQL fournie par defaut dans les depots de votre distribution. Ces versions sont souvent obsoletes (Ubuntu 24.04 LTS inclut PostgreSQL 16 par defaut alors que la version 18 est la derniere stable). Utilisez toujours le depot officiel PostgreSQL Global Development Group (PGDG) pour obtenir la derniere version stable avec les patchs de securite a jour.

Sur Ubuntu ou Debian, commencez par ajouter le depot PGDG. Executez sudo apt install -y gnupg2 puis sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'. Importez la cle GPG avec curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg. Puis installez PostgreSQL avec sudo apt update && sudo apt install -y postgresql-18 postgresql-client-18.

Apres l’installation, verifiez que le service tourne avec sudo systemctl status postgresql. Le cluster principal est cree automatiquement dans /var/lib/postgresql/18/main/ sur Debian/Ubuntu. Le fichier de configuration principal est /etc/postgresql/18/main/postgresql.conf et le fichier de controle d’acces est /etc/postgresql/18/main/pg_hba.conf.

Point important pour les VPS : si votre fournisseur propose un stockage SSD NVMe separe du disque systeme (par exemple un volume bloc chez Hetzner ou OVH), deplacez le repertoire de donnees PostgreSQL vers ce volume pour des performances optimales. Arretez PostgreSQL, deplacez le repertoire /var/lib/postgresql vers le volume monte, et creez un lien symbolique. Les IO disque sont le facteur limitant numero un des performances PostgreSQL sur un VPS — un SSD NVMe fait toute la difference.

Etape 2 : Securiser les acces (SSL, pg_hba.conf, firewall)

La securisation de PostgreSQL en production repose sur trois piliers : le chiffrement des connexions (SSL/TLS), le controle d’acces (pg_hba.conf), et le firewall systeme. Les trois doivent etre configures avant d’exposer la moindre connexion reseau.

SSL/TLS : Generez un certificat Let’s Encrypt pour votre domaine ou, si votre base n’est accessible que par IP interne, generez un certificat auto-signe. Dans postgresql.conf, configurez ssl = on, ssl_cert_file = '/etc/ssl/certs/server.crt', ssl_key_file = '/etc/ssl/private/server.key'. Forcez SSL pour les connexions distantes en ajoutant hostssl all all 0.0.0.0/0 scram-sha-256 dans pg_hba.conf — notez bien hostssl (et pas host) pour refuser les connexions non chiffrees.

pg_hba.conf : Ce fichier controle qui peut se connecter, depuis quelle adresse, et avec quelle methode d’authentification. En production, les regles sont strictes : connexions locales uniquement via peer pour le superuser postgres, connexions distantes uniquement via scram-sha-256 (jamais md5 ni trust), et restriction des adresses IP sources aux seuls serveurs applicatifs autorises. Creez un utilisateur applicatif dedie avec CREATE USER monapp WITH PASSWORD 'motdepasse_fort_32chars' LOGIN et restreignez ses droits au minimum necessaire avec GRANT CONNECT ON DATABASE monapp_db TO monapp.

Firewall : Configurez ufw pour n’accepter que les connexions SSH et PostgreSQL depuis les IP autorisees. Executez sudo ufw default deny incoming, sudo ufw allow from VOTRE_IP_SERVEUR_APP to any port 5432, sudo ufw allow 22/tcp, puis sudo ufw enable. Ne jamais ouvrir le port 5432 a 0.0.0.0/0 en production — c’est la premiere cause de compromission des bases PostgreSQL exposees sur Internet.

Parametres de securite additionnels dans postgresql.conf : activez password_encryption = scram-sha-256 (defaut depuis PostgreSQL 14), configurez log_connections = on et log_disconnections = on pour tracer les acces, et definissez log_line_prefix = '%m [%p] %q%u@%d ' pour des logs exploitables. Pour aller plus loin sur la securisation des pipelines, consultez notre guide sur la configuration de pipelines CI/CD securises.

Etape 3 : Tuner les performances pour votre VPS

La configuration par defaut de PostgreSQL est optimisee pour fonctionner sur n’importe quelle machine, y compris un Raspberry Pi avec 512 Mo de RAM. C’est prudent mais catastrophique pour les performances en production. Le tuning est l’etape qui transforme un PostgreSQL fonctionnel en un PostgreSQL performant. L’outil en ligne PGTune (pgtune.leopard.in.ua) genere une configuration optimale basee sur vos specs, mais il faut comprendre les parametres pour les ajuster ensuite.

shared_buffers : C’est le cache memoire interne de PostgreSQL. Regle empirique : 25 % de la RAM totale. Sur un VPS de 8 Go, configurez shared_buffers = 2GB. Ne depassez pas 40 % — le reste est utilise par le page cache Linux et les connexions. Sur un VPS de 4 Go (budget minimal pour la production), mettez shared_buffers = 1GB.

effective_cache_size : Indique au planificateur la quantite totale de memoire disponible pour le cache (shared_buffers + page cache OS). Regle : 75 % de la RAM totale. Sur 8 Go : effective_cache_size = 6GB. Ce parametre n’alloue pas de memoire — il informe le planificateur pour qu’il fasse de meilleurs choix (par exemple, preferer un index scan plutot qu’un sequential scan si les donnees sont probablement en cache).

work_mem : Memoire allouee par operation de tri ou de hash par connexion. Le piege : une requete complexe avec 5 operations de tri utilisera 5x work_mem. Sur un VPS avec 100 connexions simultanees et work_mem a 64 Mo, vous risquez 100 x 5 x 64 Mo = 32 Go de RAM consommee. Commencez a work_mem = 4MB pour les applications web transactionnelles, montez a 16-64 Mo pour les requetes analytiques lourdes sur des connexions dediees. Utilisez SET work_mem = '64MB' au niveau de la session pour les requetes qui en ont besoin, plutot qu’un reglage global eleve.

Configuration WAL : Les Write-Ahead Logs sont critiques pour la durabilite et la performance. Configurez wal_buffers = 64MB, min_wal_size = 1GB, max_wal_size = 4GB. Pour les charges d’ecriture intensives, augmentez checkpoint_completion_target = 0.9 (defaut depuis PostgreSQL 14) pour repartir les ecritures de checkpoint sur une plus longue periode et eviter les pics d’IO.

max_connections : La valeur par defaut (100) est souvent trop elevee pour un VPS. Chaque connexion PostgreSQL consomme environ 5-10 Mo de RAM. Sur un VPS de 4-8 Go, limitez a 50-100 connexions et utilisez un pooler de connexions (PgBouncer ou Pgpool-II) devant PostgreSQL. PgBouncer en mode transaction pooling est la solution standard : il maintient 200+ connexions applicatives avec seulement 20-30 connexions reelles vers PostgreSQL. L’installation est simple : sudo apt install -y pgbouncer et une configuration de 10 lignes dans /etc/pgbouncer/pgbouncer.ini.

Etape 4 : Configurer des sauvegardes automatisees et testees

Une base de donnees sans sauvegarde testee est une base de donnees perdue. C’est la regle numero un du DBA, et elle s’applique d’autant plus sur un VPS ou les pannes disque, les erreurs humaines et les compromissions sont des realites quotidiennes. PostgreSQL offre trois niveaux de sauvegarde complementaires — les trois doivent etre configures.

Niveau 1 — pg_dump quotidien. C’est la sauvegarde logique : un export SQL complet et coherent de la base. Executez pg_dump -Fc -Z 9 -j 4 monapp_db > /backups/monapp_db_$(date +%Y%m%d_%H%M%S).dump. Le flag -Fc produit un format custom compresse, -Z 9 applique la compression maximale, et -j 4 parallelise l’export sur 4 threads. Automatisez avec un cron job quotidien a 3h du matin et envoyez le dump vers un stockage distant (Backblaze B2, Scaleway Object Storage, ou un second VPS dans un autre datacenter) avec rclone ou restic. Conservez 7 jours de dumps quotidiens et 4 semaines de dumps hebdomadaires.

Niveau 2 — pg_basebackup hebdomadaire. C’est la sauvegarde physique : une copie binaire du repertoire de donnees PostgreSQL. Executez pg_basebackup -D /backups/base_$(date +%Y%m%d) -Ft -z -Xs -P. Le flag -Ft produit un tar, -z compresse, -Xs inclut les WAL necessaires en mode streaming, et -P affiche la progression. La restauration est plus rapide qu’un pg_dump sur les bases volumineuses car elle n’a pas besoin de reconstruire les index.

Niveau 3 — Archivage continu des WAL (PITR). C’est le filet de securite ultime : en archivant les Write-Ahead Logs en continu, vous pouvez restaurer la base a n’importe quel instant dans le passe (Point-in-Time Recovery). Dans postgresql.conf, configurez archive_mode = on et archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'. En production, utilisez pgBackRest ou barman qui gerent l’archivage, la compression, le chiffrement et la verification d’integrite automatiquement.

Tester les restaurations : Planifiez un test de restauration mensuel. Restaurez le dernier dump pg_dump sur un serveur de test, verifiez que les donnees sont coherentes, et mesurez le temps de restauration (RTO). Restaurez un pg_basebackup + replay des WAL pour valider le PITR. Un backup que vous n’avez jamais teste n’est pas un backup, c’est un espoir. Les pratiques de securite des dependances open source s’appliquent egalement aux outils de sauvegarde.

Etape 5 : Mettre en place le monitoring (Prometheus + Grafana)

Un PostgreSQL en production sans monitoring est comme un avion sans tableau de bord — vous ne savez pas que vous avez un probleme jusqu’au crash. Le monitoring PostgreSQL repose sur trois piliers : les metriques systeme (CPU, RAM, IO disque, reseau), les metriques PostgreSQL (connexions, requetes, locks, cache hit ratio, replication lag), et les alertes (seuils qui declenchent des notifications).

La stack de reference open source est Prometheus + postgres_exporter + Grafana. Installez postgres_exporter (un binaire unique) qui se connecte a PostgreSQL et expose les metriques au format Prometheus. Configurez Prometheus pour scraper cet exporter toutes les 15 secondes. Importez le dashboard Grafana officiel pour PostgreSQL (dashboard ID 9628 ou 14114) et vous obtenez immediatement une visibilite sur les metriques critiques.

Les metriques critiques a surveiller en priorite : le cache hit ratio (doit rester au-dessus de 99 % — en dessous, augmentez shared_buffers ou la RAM), le nombre de connexions actives vs max_connections (alerte a 80 %), les locks en attente (toute requete bloquee plus de 30 secondes doit declencher une alerte), le taux de transactions par seconde (TPS) pour detecter les pics anormaux, et la taille des tables et index pour anticiper les besoins de stockage. Activez pg_stat_statements pour identifier les requetes les plus lentes et les plus frequentes.

Pour les alertes, configurez Alertmanager (composant de Prometheus) pour envoyer des notifications Slack, email ou PagerDuty sur les seuils critiques. Les alertes minimales pour une base de production : connexions a 80 % de max_connections, cache hit ratio sous 95 %, disque a 85 % de capacite, replication lag superieur a 30 secondes (si replication configuree), et absence de backup reussi depuis plus de 36 heures. Notre guide sur l’auto-hebergement de Prometheus + Grafana + Loki detaille l’installation complete de la stack d’observabilite.

Etape 6 : Configurer la replication pour la haute disponibilite

Un seul serveur PostgreSQL est un single point of failure. En production, la haute disponibilite (HA) necessite au minimum un replica en streaming replication pret a prendre le relais en cas de panne du serveur principal. La bonne nouvelle : la streaming replication PostgreSQL est simple a mettre en place et ne necessite aucune extension.

Sur le serveur principal (primary), dans postgresql.conf, configurez wal_level = replica, max_wal_senders = 5, wal_keep_size = 1GB. Creez un utilisateur de replication : CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'motdepasse_replication'. Dans pg_hba.conf, autorisez la connexion de replication depuis l’IP du standby : hostssl replication replicator IP_STANDBY/32 scram-sha-256.

Sur le serveur standby, arretez PostgreSQL, supprimez le repertoire de donnees, et initialisez-le depuis le primary avec pg_basebackup -h IP_PRIMARY -U replicator -D /var/lib/postgresql/18/main -Xs -P -R. Le flag -R cree automatiquement le fichier standby.signal et configure les parametres de connexion au primary. Demarrez PostgreSQL sur le standby — il commencera immediatement a recevoir et rejouer les WAL du primary.

Pour le failover automatique, utilisez Patroni (solution de reference open source) ou repmgr. Patroni, developpe par Zalando et utilise en production par des centaines d’entreprises, gere la detection de panne, la promotion automatique du standby en primary, et la reconfiguration des clients. Il s’appuie sur un store de consensus distribue (etcd, Consul ou ZooKeeper) pour eviter les split-brain. Sur un VPS, la configuration minimale est un primary + un standby + un temoin etcd (qui peut tourner sur un VPS minimal a 3 €/mois).

Astuce pour les budgets serres : meme si vous ne pouvez pas vous offrir un standby dedie, configurez la streaming replication vers un VPS dans un autre datacenter et utilisez-le comme replica en lecture seule. Vos requetes de reporting et d’analytics tournent sur le standby, delestant le primary des charges de lecture. Le cout supplementaire (10-15 €/mois pour un VPS replica) est derisoire par rapport au cout d’une perte de donnees ou d’une indisponibilite prolongee.

Etape 7 : Automatiser le deploiement et la maintenance avec Ansible et CI/CD

Toute la configuration decrite dans les etapes 1 a 6 doit etre codifiee et automatisee. Si votre configuration PostgreSQL de production vit uniquement dans les fichiers du serveur et dans la memoire du DBA qui l’a installee, vous avez un probleme de bus factor. L’automatisation avec Ansible (ou Terraform pour le provisionnement) garantit la reproductibilite, la documentation et la reprise rapide en cas de sinistre.

Creez un playbook Ansible qui couvre l’ensemble du deploiement : installation du depot PGDG et de PostgreSQL, copie des fichiers postgresql.conf et pg_hba.conf templatises (avec les variables specifiques a chaque environnement), generation des certificats SSL, creation de l’utilisateur applicatif et de la base, configuration de PgBouncer, installation et configuration de postgres_exporter, et mise en place des cron jobs de sauvegarde. L’ensemble du playbook doit etre idempotent : vous pouvez l’executer 10 fois et le resultat sera le meme.

CI/CD pour les migrations de schema : Les changements de schema (CREATE TABLE, ALTER TABLE, CREATE INDEX) doivent etre versionnes et deployes via un outil de migration. Les outils de reference pour PostgreSQL sont Flyway (Java, fichiers SQL numerotes), Alembic (Python, migrations Python), golang-migrate (Go, fichiers SQL), ou Sqitch (Perl, approche change-based). Integrez l’outil de migration dans votre pipeline CI/CD : chaque merge sur la branche main declenche l’application automatique des migrations en staging, puis en production apres validation.

Maintenance automatisee : Configurez des cron jobs pour les taches de maintenance recurrentes. Le ANALYZE des tables est generalement gere par l’autovacuum, mais il est utile de forcer un ANALYZE complet apres un deploiement de migrations. Avec l’arrivee de PostgreSQL 19, le REPACK natif permettra de planifier la reorganisation des tables volumineuses en cron job sans impact sur la disponibilite — une avancee majeure detaillee dans notre article sur les nouveautes de PostgreSQL 19.

Infrastructure as Code complete : Pour une approche rigoureuse, combinez Terraform (provisionnement du VPS, des volumes, du firewall cloud et du DNS), Ansible (configuration du systeme et de PostgreSQL), et votre pipeline CI/CD (migrations de schema et deploiement applicatif). Stockez tout dans un repository Git prive, avec des secrets geres par SOPS ou Vault. Cette approche permet de reconstruire l’integralite de votre infrastructure de base de donnees en moins d’une heure a partir d’un repository Git et d’un backup — c’est votre plan de reprise d’activite (PRA). Pour securiser vos workflows GitHub Actions, consultez notre guide sur la securite des workflows GitHub Actions.

Questions frequentes