Pourquoi réévaluer RDS en 2026
Amazon RDS for PostgreSQL est une base managée solide, mais son modèle de facturation est conçu pour que la facture suive la croissance de façon non linéaire. Chaque composant se facture séparément : le compute de l'instance, le stockage gp3 au Go, les IOPS provisionnés, les nœuds de réplication en Multi-AZ, les sauvegardes au-delà de la fenêtre incluse, les transferts de données sortants. Une instance db.r6g.4xlarge en Multi-AZ avec 500 Go de stockage gp3 dépasse 3 000 $/mois sur us-east-1 au tarif à la demande. La même charge de travail sur un cluster Hetzner Cloud à trois nœuds tourne autour de 835 $/mois — soit une économie de 2 315 $/mois, environ 27 800 $ sur douze mois (source : selfhost.dev, mai 2026, HN item #48816129). Ce chiffre concerne un cluster haute disponibilité complet. Pour une base de développement, de staging ou un workload métier sans réplication, un nœud unique suffit à une fraction du coût. Le contexte tarifaire a aussi évolué en 2026 : Hetzner a revu ses grilles en avril puis en juin 2026, OVHcloud a augmenté ses VPS en avril 2026. Ces hausses modifient les chiffres absolus — elles ne changent pas la logique : l'auto-hébergement reste structurellement moins coûteux dès lors que la base dépasse quelques dizaines de Go et que le trafic impose une instance non-burstable. La question n'est plus de savoir si l'auto-hébergement est moins cher — les chiffres le confirment — mais de savoir si la charge opérationnelle vaut l'économie réalisée.
Ce que vous gagnez en passant sur VPS
- Coût fixe et prévisible — pas de facturation au Go, aux IOPS supplémentaires ni aux connexions simultanées ; vous dimensionnez votre VPS une fois et le prix ne change pas avec le volume de requêtes.
- Extensions libres — PostGIS, TimescaleDB, pg_partman, pgvector, citus : aucune restriction arbitraire sur les extensions, contrairement aux instances RDS où la liste est fermée et les extensions non supportées absentes.
- Accès root et configuration fine —
postgresql.conf,pg_hba.conf,huge_pages,wal_level, poolers de connexion : vous ajustez chaque paramètre sans passer par une console cloud et sans restrictions sur les outils système. - Versions maîtrisées — vous choisissez quand passer de PostgreSQL 16 à 17, sans fenêtre de maintenance imposée ni dépréciation forcée par le fournisseur.
- Données dans votre périmètre — choix du datacenter, chiffrement des volumes selon votre politique interne, pas de transfert de données inter-région facturé à chaque lecture analytique.
- Portabilité totale —
pg_dumpou la réplication logique migrent vos données vers n'importe quel autre hôte sans friction de fournisseur et sans frais de sortie. - Option administration disponible — si la charge opérationnelle reste l'objection principale, l'option administration VPS couvre les tâches courantes (mises à jour, monitoring, sauvegardes) ; le contrôle reste le vôtre, la charge non.
PostgreSQL sur VPS vs Amazon RDS : tableau comparatif
| Critère | PostgreSQL sur VPS | Amazon RDS for PostgreSQL |
|---|---|---|
| Coût mensuel (workload standard) | Fixe — proportionnel au serveur choisi | Variable — compute + stockage + IOPS + Multi-AZ + sorties réseau |
| Exemple haute dispo (3 nœuds / Multi-AZ) | ~835 $/mois (Hetzner CCX53 cluster, mai 2026) | ~3 150 $/mois (db.r6g.4xlarge Multi-AZ, us-east-1) |
| Extensions PostgreSQL | Toutes, y compris PostGIS, pgvector, TimescaleDB, citus | Liste restreinte ; extensions non officielles absentes |
| Accès root / OS | Oui — choix d'OS, Docker, cron, tuning kernel, pgBouncer | Non — API AWS uniquement, paramètres restreints |
| Mises à jour de version | À votre rythme, sans fenêtre de maintenance imposée | Planifiées ou imposées par AWS à la dépréciation |
| Charge opérationnelle | Sauvegardes, mises à jour, monitoring à gérer | Automatisée par AWS : sauvegardes, patches, failover |
| Portabilité | Totale — `pg_dump` ou réplication logique, sans frais | Liée à l'écosystème AWS, export de données payant |
Prérequis avant de migrer
Un VPS de 4 Go de RAM et 2 vCPU suffit pour la plupart des bases de données d'applications web inférieures à 50 Go avec un trafic moyen et des connexions inférieures à 50 simultanées. Pour une base plus sollicitée, un schéma analytique avec beaucoup de jointures, ou un service exposé à des pics de trafic, prévoir 8 Go de RAM minimum. Le stockage SSD NVMe est indispensable : les accès aléatoires de PostgreSQL sur un disque rotatif ou un SSD SATA d'entrée de gamme dégradent les performances de façon significative, particulièrement lors des vides de cache après un redémarrage. Un accès root est requis — c'est le cas sur tout VPS cloud. Côté réseau, vous aurez besoin d'une adresse IPv4 fixe ou d'un nom de domaine interne pour pointer vos connexions applicatives. Prévoyez enfin une fenêtre de migration où les deux bases tournent en parallèle : l'application pointe sur RDS, vous remplissez le VPS, vous vérifiez la cohérence, puis vous basculez la variable de connexion. La durée dépend du volume : un dump de 5 Go restauré en parallèle prend quelques minutes ; 200 Go peuvent en prendre plusieurs dizaines.
Installer et configurer PostgreSQL sur un VPS
Installer PostgreSQL depuis le dépôt officiel PGDG
Sur Ubuntu 24.04 ou Debian 12, ajoutez le dépôt PostgreSQL Global Development Group pour obtenir la version courante plutôt que celle packagée par la distribution : curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg puis echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list. Ensuite : sudo apt update && sudo apt install -y postgresql-17.
Créer un utilisateur et une base dédiés
Connectez-vous en tant que postgres : sudo -u postgres psql. Puis créez un utilisateur applicatif et une base isolée : CREATE USER monapp WITH PASSWORD 'mot-de-passe-fort'; suivi de CREATE DATABASE monapp OWNER monapp;. Quittez avec \q. N'utilisez jamais le rôle postgres dans votre chaîne de connexion applicative : un bug ou une injection opèrerait avec les droits superutilisateur.
Configurer postgresql.conf pour la charge attendue
Le fichier de configuration se trouve dans /etc/postgresql/17/main/postgresql.conf. Paramètres clés pour un VPS de 4 Go : shared_buffers = 1GB (25 % de la RAM), effective_cache_size = 3GB, work_mem = 16MB, maintenance_work_mem = 256MB, max_connections = 100. Relancez après toute modification : sudo systemctl restart postgresql. Pour un VPS de 8 Go, montez shared_buffers à 2 Go et effective_cache_size à 6 Go.
Restreindre les connexions réseau dans pg_hba.conf
Par défaut, PostgreSQL n'écoute que sur localhost. Si votre application est sur le même serveur, c'est parfait — ne modifiez rien. Pour une application sur une autre machine, éditez /etc/postgresql/17/main/pg_hba.conf et ajoutez : host monapp monapp <IP-application>/32 scram-sha-256. Dans postgresql.conf, posez listen_addresses = 'localhost,<IP-VPS>'. Rechargez : sudo systemctl reload postgresql.
Exporter depuis RDS et importer sur le VPS
Sur une machine avec accès aux deux hôtes, exportez avec le format custom de pg_dump : pg_dump -h <endpoint-rds> -U <user> -Fc <base> -f dump.pgc. Puis importez sur le VPS en parallèle sur 4 workers : pg_restore -h localhost -U monapp -d monapp -j 4 dump.pgc. Vérifiez le compte de lignes sur quelques tables critiques avant de basculer la connexion applicative.
Automatiser les sauvegardes avec un cron
Créez /usr/local/bin/pg-backup.sh : PGPASSWORD='mot-de-passe' pg_dump -U monapp monapp -Fc > /var/backups/pg/monapp-$(date +%Y%m%d-%H%M).pgc. Rendez-le exécutable : chmod +x /usr/local/bin/pg-backup.sh. Ajoutez la crontab : 0 3 * * * /usr/local/bin/pg-backup.sh. Conservez les dumps chiffrés sur un stockage externe ou transférez-les via rsync vers un second VPS pour garantir une copie hors site.
Activer la supervision avec pg_stat_statements
Dans postgresql.conf, ajoutez shared_preload_libraries = 'pg_stat_statements'. Relancez PostgreSQL, puis activez l'extension dans votre base : CREATE EXTENSION pg_stat_statements;. Identifiez ensuite les requêtes lentes : SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;. Cela remplace avantageusement les métriques Performance Insights de RDS pour le diagnostic quotidien.
Durcissement post-install : désactivez le compte postgres système pour les connexions SSH (sudo passwd -l postgres) ; activez ssl = on dans postgresql.conf avec un certificat Let's Encrypt ou auto-signé pour chiffrer les connexions réseau entre l'application et la base ; activez ufw et n'ouvrez le port 5432 qu'aux IP applicatives connues (sudo ufw allow from <IP-app> to any port 5432). Ces trois gestes couvrent l'essentiel de la surface d'attaque d'une base exposée sur un réseau non privé.
Dépannage : erreurs courantes après migration
Les erreurs ci-dessous apparaissent fréquemment dans les premières heures après une migration RDS vers un VPS autonome. Chacune a un message précis et un remède ciblé — lisez le message complet avant d'agir, car plusieurs causes distinctes partagent le même code d'erreur.
Cinq erreurs fréquentes et leurs solutions
FATAL: password authentication failed for user "monapp"— le mot de passe envoyé ne correspond pas à celui en base, ou la méthode d'authentification diffère (md5vsscram-sha-256). Vérifiez la ligne danspg_hba.confet rechargez :sudo systemctl reload postgresql. Si vous avez changé le mot de passe depuis psql, assurez-vous que la chaîne de connexion applicative reflète le nouveau.FATAL: no pg_hba.conf entry for host "<IP>", user "monapp", database "monapp", SSL off— l'IP source de la connexion n'est pas autorisée danspg_hba.conf. Ajoutez l'entrée manquante pour cet IP et rechargez. Si vous n'utilisez pas SSL, vérifiez que la ligne portehostet nonhostssl.ERROR: extension "uuid-ossp" does not exist(ou toute extension absente sur RDS) — l'extension est disponible dans PostgreSQL mais pas activée dans cette base. Exécutez depuis psql :CREATE EXTENSION IF NOT EXISTS "uuid-ossp";. Si l'extension manque au paquet, installez :sudo apt install postgresql-17-<extension>.FATAL: remaining connection slots are reserved for non-replication superuser connections—max_connectionsest atteint. Augmentez-le danspostgresql.confet relancez, ou installezpgBouncerpour mutualiser les connexions : un pool de 10 connexions réelles peut servir des centaines de clients applicatifs.pg_restore: error: could not execute query: ERROR: role "rdsadmin" does not exist— RDS crée des rôles internes absents de tout PostgreSQL hors AWS. Ajoutez--no-owner --no-privilegesà la commandepg_restore:pg_restore --no-owner --no-privileges -h localhost -U monapp -d monapp dump.pgc. Les objets sont importés sans tenter de réassigner la propriété aux rôles RDS.
Ce que ce comparatif ne couvre pas — et ce qu'il faut savoir avant de décider
L'auto-hébergement transfère vers votre équipe la charge de gestion des sauvegardes, des mises à jour de sécurité et du monitoring. C'est une réalité, pas un argument contre : elle s'évalue face au coût économisé. Pour un développeur seul ou une petite équipe sans expertise opérationnelle, l'option administration VPS couvre les tâches courantes — mises à jour, surveillance, sauvegardes vérifiées — sans que vous ayez à les orchestrer. RDS reste pertinent dans deux situations bien précises : quand la résilience multi-région est un prérequis contractuel et que vous n'avez pas les ressources pour la mettre en place manuellement, et quand la facturation à la consommation est réellement avantageuse pour une base très petite qui tourne peu (un VPS tourne et se facture 24 h/24 même à charge nulle). Pour tout le reste — base de taille moyenne, workload stable, équipe avec un minimum de compétences système — les chiffres plaident clairement pour l'auto-hébergement. Les articles <a href="/blog/heberger-postgresql-vps">PostgreSQL sur VPS : installation et bonnes pratiques</a> et <a href="/blog/postgresql-fin-de-vie-planifier-montee-version">PostgreSQL en fin de vie : planifier la montée de version</a> complètent ce guide sur le volet opérationnel et la gestion des versions majeures.
