Migrer PostgreSQL depuis RDS, Cloud SQL ou un BaaS vers un VPS

Les bases managées résolvent un problème réel : elles éliminent les opérations du premier jour (installation, réplication, sauvegardes automatiques). Mais leur modèle économique est conçu pour que la facture suive la croissance de façon non linéaire. Sur AWS RDS, chaque composant se facture séparément : le compute de l'instance, le stockage gp3 au Go, les IOPS provisionnés, le nœud secondaire Multi-AZ, les sauvegardes au-delà de la fenêtre incluse, les transferts de données sortants. Une instance db.r6g.xlarge en Multi-AZ avec 200 Go de stockage gp3 dépasse facilement 800 $/mois sur us-east-1 ; à 500 Go, on franchit 3 000 $/mois. La même charge sur un VPS dédié tourne à une fraction de ce coût.

Le coût n'est pas la seule variable. Les contraintes d'extensions sont un frein technique concret : pgvector sur RDS est disponible depuis 2023, mais pg_graphql ou d_btree_gist dans certaines versions ne le sont pas. Sur Supabase, le catalogue est plus large, mais il est lié à la plateforme — déplacer la base signifie ré-évaluer chaque extension. La conformité des données est un troisième moteur : stocker une base de données dans le datacenter de votre choix, sans transfert inter-région facturable, change la donne pour les architectures soumises au RGPD ou à des politiques de résidence des données. Enfin, la latence entre la base et l'application diminue mécaniquement quand les deux résident sur la même machine ou dans le même réseau privé — une optimisation gratuite sur un VPS, impossible sans frais supplémentaires sur une offre managée.

Avant de lancer le premier pg_dump, quatre points conditionnent le succès de la migration.

Version PostgreSQL source vs destination. Un dump produit par pg_dump d'une version N peut être restauré sur une version N ou supérieure, jamais inférieure. Vérifiez la version source : psql -h <endpoint> -U <user> -c 'SELECT version();'. Sur le VPS, installez la même version majeure ou supérieure depuis le dépôt PGDG. Une migration de version (ex. PostgreSQL 14 → 17) est possible en une passe, mais les changements de comportement (types de données, fonctions dépréciées) méritent un test applicatif complet avant la bascule.

Extensions actives. Listez les extensions installées sur la source : SELECT extname, extversion FROM pg_extension ORDER BY extname;. Certaines sont universellement disponibles (uuid-ossp, hstore, pgcrypto). D'autres nécessitent un paquet système supplémentaire (postgis → postgresql-17-postgis-3) ou une compilation depuis les sources (pgvector → paquet postgresql-17-pgvector sur Debian/Ubuntu). Les extensions propres à Supabase (pg_graphql, pg_net, pgsodium) n'existent pas dans un PostgreSQL vanilla : planifiez leur remplacement avant de migrer.

Taille de la base. SELECT pg_size_pretty(pg_database_size('<base>')); donne la taille logique. Le dump pg_dump -Fc produit un fichier compressé significativement plus petit. Prévoyez sur le VPS l'espace disque nécessaire pour le dump lui-même, la base restaurée, et 20 % de marge pour les WAL et les index temporaires de restauration.

Connexions actives. Une base sous trafic ne peut pas être dumpée proprement avec des transactions longues en cours. Vérifiez : SELECT count(*), state FROM pg_stat_activity GROUP BY state;. Si des connexions en état idle in transaction persistent depuis plusieurs minutes, identifiez et terminez ces sessions avant de lancer le dump de migration.

RDS impose TLS sur les connexions entrantes (rds.force_ssl = 1 par défaut sur les instances récentes). Le flag --sslmode=require est donc indispensable sur pg_dump, sans quoi la connexion est refusée ou établie sans chiffrement selon la configuration de l'instance.

Utilisez de préférence un endpoint de lecture (Read Replica) pour le dump : cela évite d'ajouter de la charge sur l'instance primaire pendant la migration.

# Dump depuis RDS (endpoint de lecture si disponible)
export PGPASSWORD='votre-mot-de-passe'
pg_dump \
  -h votre-instance.xxxx.rds.amazonaws.com \
  -U votre_user \
  --sslmode=require \
  -Fc \
  -f /tmp/dump-rds.pgc \
  votre_base

Puis restaurez sur le VPS en parallèle pour accélérer l'import :

pg_restore \
  --no-owner \
  --no-privileges \
  -h localhost \
  -U votre_user_vps \
  -d votre_base \
  -j 4 \
  /tmp/dump-rds.pgc

--no-owner et --no-privileges sont indispensables : RDS crée des rôles internes (rdsadmin, rds_superuser) absents de tout PostgreSQL hors AWS. Sans ces flags, pg_restore échoue en tentant de réassigner la propriété des objets à ces rôles inexistants.

Variables RDS non transférables : rds.force_ssl, rds.log_retention_period, rds_superuser et tout paramètre préfixé rds. sont des paramètres de système propriétaire AWS — ils n'existent pas dans postgresql.conf standard. Si votre application vérifie la valeur de rds.force_ssl via SHOW rds.force_ssl, elle obtiendra une erreur sur le VPS. Remplacez cette vérification par SHOW ssl.

Cloud SQL propose deux voies d'export : le Cloud SQL Auth Proxy (recommandé pour les connexions programmatiques) et l'export vers un bucket GCS (recommandé pour les dumps volumineux ou les migrations unidirectionnelles).

Via Cloud SQL Auth Proxy (connexion directe, adapté aux bases < 10 Go) :

# Démarrer le proxy en arrière-plan
cloud_sql_proxy -instances=mon-projet:europe-west1:mon-instance=tcp:5433 &

# Dump via le proxy (port local 5433)
export PGPASSWORD='votre-mot-de-passe'
pg_dump \
  -h 127.0.0.1 \
  -p 5433 \
  -U votre_user \
  -Fc \
  -f /tmp/dump-cloudsql.pgc \
  votre_base

Via export GCS (recommandé pour les bases volumineuses) :

# Export depuis la console gcloud (format SQL ou CSV)
gcloud sql export sql mon-instance \
  gs://mon-bucket/dump-cloudsql.sql \
  --database=votre_base \
  --offload

# Téléchargement local
gsutil cp gs://mon-bucket/dump-cloudsql.sql /tmp/

# Import sur le VPS (format SQL)
psql -h localhost -U votre_user_vps -d votre_base \
  -f /tmp/dump-cloudsql.sql

Notez que gcloud sql export sql produit un fichier SQL brut, pas un fichier au format custom pg_dump -Fc. L'import avec psql -f est plus lent que pg_restore -j mais fonctionne sur ce format. Pour un dump au format custom compatible pg_restore, utilisez obligatoirement le Cloud SQL Auth Proxy avec pg_dump -Fc.

Pièges Cloud SQL : le flag --offload déplace le traitement du dump vers un worker secondaire et réduit l'impact sur l'instance primaire. Sans lui, un dump long peut affecter les performances en production. Autre piège : Cloud SQL crée un utilisateur cloudsqladmin qui apparaît dans certains objets de la base — appliquez --no-owner --no-privileges à la restauration comme pour RDS.

Supabase expose un accès direct à PostgreSQL via une URI de connexion disponible dans les paramètres du projet (Settings > Database > Connection string > URI). Cet accès fonctionne avec pg_dump standard.

# Récupérer l'URI depuis le tableau de bord Supabase
# Format : postgresql://postgres:[PASSWORD]@db.[PROJECT_REF].supabase.co:5432/postgres

export DATABASE_URL="postgresql://postgres:[email protected]:5432/postgres"

pg_dump \
  "$DATABASE_URL" \
  --sslmode=require \
  -Fc \
  --no-owner \
  --no-privileges \
  -f /tmp/dump-supabase.pgc

Extensions présentes sur Supabase absentes d'un VPS vanilla. C'est le principal piège de la migration depuis Supabase. Le catalogue d'extensions de Supabase est significativement plus large que celui d'une installation PostgreSQL standard :

- pgvector : disponible sur Supabase, doit être installé manuellement sur le VPS (sudo apt install postgresql-17-pgvector sur Debian/Ubuntu, puis CREATE EXTENSION vector;).
- pg_graphql : extension Supabase propriétaire qui expose un endpoint GraphQL automatique sur la base. Elle n'existe pas dans les dépôts APT standard. Si votre application l'utilise, vous devez soit compiler l'extension depuis les sources (Rust + cargo-pgrx requis), soit réécrire la couche d'accès GraphQL en dehors de la base.
- pg_net : permet des requêtes HTTP depuis des fonctions SQL. Absente des paquets standard — réécrire les usages en dehors de la base de données.
- pgsodium : chiffrement au niveau de la base (column-level encryption). Présente dans certains dépôts tiers, mais son intégration avec Vault est spécifique à Supabase.
- http : extension communautaire disponible via postgresql-17-http sur Debian/Ubuntu.

Avant de lancer le dump, recensez exhaustivement les extensions actives avec SELECT extname FROM pg_extension WHERE extname NOT IN ('plpgsql'); et vérifiez pour chacune si un paquet APT existe, si une compilation est nécessaire, ou si la fonctionnalité doit migrer hors de la base.

Quatre vérifications à effectuer dans l'heure suivant la bascule.

Comptage de lignes. Sur les dix tables les plus volumineuses, comparez les comptages source et destination. Un écart nul confirme que toutes les transactions ont été capturées ; un écart résiduel de quelques lignes peut indiquer des transactions encore en vol au moment de la bascule — vérifiez les logs applicatifs pour les identifier.

Checksums. Sur les tables critiques (transactions, commandes, données sensibles), calculez un checksum de contrôle : SELECT md5(string_agg(id::text || montant::text, ',' ORDER BY id)) FROM commandes; et comparez le résultat sur les deux instances. Un checksum identique confirme l'intégrité des données ligne à ligne.

Test des extensions. Pour chaque extension utilisée par l'application, exécutez une requête de test minimale : SELECT 'test'::vector(3) pour pgvector, SELECT gen_random_uuid() pour pgcrypto, SELECT ST_AsText(ST_MakePoint(1, 1)) pour PostGIS. Une extension manquante ou mal configurée remonte immédiatement.

Connexions applicatives. Vérifiez dans les logs de l'application que les connexions s'établissent bien sur le VPS et non sur l'ancienne base : grep 'DATABASE_URL\|database connection' /var/log/app/*.log. Vérifiez aussi que les connexions SSL sont actives : SELECT ssl, client_addr FROM pg_stat_ssl JOIN pg_stat_activity USING (pid) WHERE client_addr IS NOT NULL LIMIT 5;.

Ce guide couvre la migration unidirectionnelle — la procédure la plus courante pour quitter un fournisseur managé. Trois sujets complémentaires méritent d'être explorés selon votre contexte.

PostgreSQL auto-hébergé vs Amazon RDS — un comparatif ROI chiffré entre les deux modèles, avec les seuils de taille de base et de trafic à partir desquels l'auto-hébergement devient clairement avantageux.

Héberger PostgreSQL sur un VPS — la configuration détaillée post-installation : postgresql.conf, pg_hba.conf, pgBouncer, monitoring avec pg_stat_statements, sauvegardes automatisées et durcissement réseau.

PostgreSQL haute disponibilité avec Patroni sur VPS — si votre SLA exige un failover automatique, Patroni sur un cluster de trois nœuds (primaire + deux réplicas) reproduit les garanties de Multi-AZ RDS ou Cloud SQL HA, sans le surcoût fournisseur.