Migrer vers Lampion
Lampion utilise du PostgreSQL standard. Aucune couche propriétaire, aucun fork. Migrez depuis n'importe quel provider en quelques minutes avec pg_dump et pg_restore.
Vue d'ensemble
Une migration vers Lampion suit toujours le même schéma : exporter, créer, restaurer, vérifier, basculer. La majorité des migrations prennent moins de 10 minutes pour une base < 5 GB.
Prérequis — PostgreSQL client tools (pg_dump, pg_restore, psql) en version ≥ 17. Sur Debian/Ubuntu : apt install postgresql-client-17. Sur macOS : brew install postgresql@17.
Exporter la base source
Récupérez un dump complet depuis votre provider actuel. Le format custom (-Fc) est recommandé : il est compressé, supporte la restauration parallèle, et permet de filtrer à la restauration.
$ pg_dump "postgresql://user:pass@source.host:5432/mydb" \ --format=custom \ --no-owner \ --no-privileges \ --file=mydb.dump -- Dump terminé : mydb.dump (124 MB)
Pourquoi --no-owner et --no-privileges ? Lampion utilise son propre rôle cloud_admin. Ces flags évitent les erreurs role "xxx" does not exist à la restauration.
Créer le projet Lampion
Créez un projet via la console ou l'API. Vous récupérez immédiatement une connection string prête à l'emploi.
$ curl -X POST \ -H "Authorization: Bearer $TOKEN" \ -d '{"name":"my-app"}' \ api.lampion.cloud/v1/projects {"connection_string":"...", "pg_password":"..."}
Restaurer le dump
Utilisez la connection string Lampion comme cible. Le flag --jobs=4 parallélise la restauration et accélère le processus pour les grosses bases.
$ pg_restore \ --dbname="postgresql://cloud_admin:xxx@db-test.lampion.cloud:5432/ep-abc.postgres?sslmode=require" \ --no-owner \ --no-privileges \ --jobs=4 \ --verbose \ mydb.dump pg_restore: connecting to database for restore pg_restore: creating SCHEMA "public" pg_restore: creating TABLE "public.users" pg_restore: processing data for table "public.users" pg_restore: creating INDEX "users_email_key" -- Restauration terminée en 47 secondes
Bases > 10 GB — Augmentez temporairement la taille du compute via la console (4-8 CU) avant la restauration, puis revenez à 0.25 CU. Vous économisez en temps de restore et en coût.
Vérifier la migration
Comparez le nombre de tables, d'index, et le compte de lignes pour chaque table critique.
# Nombre de tables $ psql "$LAMPION_URL" -c "\dt" # Compte de lignes par table $ psql "$LAMPION_URL" -c " SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC;" # Index présents $ psql "$LAMPION_URL" -c "\di" # Comparer avec la source $ psql "$SOURCE_URL" -c " SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC;"
ANALYZE post-restore — pg_restore ne lance pas ANALYZE automatiquement. Lancez VACUUM ANALYZE pour que le planner ait des statistiques fraîches sur vos tables migrées.
Basculer le trafic
Mettez à jour la DATABASE_URL de vos applications. Pour minimiser le downtime, passez en lecture seule sur la source pendant le switch.
Guides par provider
Spécificités par fournisseur source. La logique reste la même partout : exporter, restaurer, switcher.
Neon utilise la même architecture (pageserver/safekeeper). La migration est triviale.
# 1. Récupérer la connection string Neon (Dashboard → Connection Details) $ pg_dump "postgresql://user:pass@ep-xxx.eu-central-1.aws.neon.tech/neondb?sslmode=require" \ -Fc --no-owner --no-privileges -f neon.dump # 2. Restore sur Lampion $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 neon.dump
auth Supabase ajoute des schémas système (auth, storage, realtime). Filtrez sur public uniquement, sauf si vous voulez tout migrer.
# Récupérer le mot de passe DB (Settings → Database) $ pg_dump "postgresql://postgres:[PASSWORD]@db.[REF].supabase.co:5432/postgres" \ --schema=public \ -Fc --no-owner --no-privileges -f supabase.dump $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 supabase.dump
Assurez-vous que votre IP est dans le security group RDS. Pour les grosses instances, lancez le dump depuis une EC2 dans le même VPC pour éviter les coûts de transfert sortant.
# Depuis votre machine (ou une EC2 dans le même VPC) $ pg_dump "postgresql://admin:pass@mydb.xxx.rds.amazonaws.com:5432/myapp?sslmode=require" \ -Fc --no-owner --no-privileges -f rds.dump $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 rds.dump
Heroku CLI fournit pg:backups pour générer un dump compressé téléchargeable.
# 1. Capturer un backup $ heroku pg:backups:capture -a my-app # 2. Télécharger le dump $ heroku pg:backups:download -a my-app -- latest.dump (89 MB) # 3. Restore sur Lampion $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 latest.dump
Activez l'IP publique temporairement, ou utilisez le Cloud SQL Auth Proxy pour vous connecter en local.
# Avec Cloud SQL Auth Proxy $ cloud-sql-proxy --port 5433 my-project:europe-west1:my-instance & $ pg_dump "postgresql://postgres:pass@127.0.0.1:5433/myapp" \ -Fc --no-owner --no-privileges -f cloudsql.dump $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 cloudsql.dump
Si vous hébergez votre propre PostgreSQL, vous pouvez lancer pg_dump directement sur l'hôte ou via SSH. Avantage : pas de limite de bande passante imposée par le provider.
# Sur le serveur source $ sudo -u postgres pg_dump myapp -Fc --no-owner --no-privileges -f /tmp/myapp.dump # Transférer en local $ scp user@source.host:/tmp/myapp.dump . # Restore sur Lampion $ pg_restore -d "$LAMPION_URL" --no-owner --no-privileges -j 4 myapp.dump
Pièges courants
Les problèmes les plus fréquents et comment les résoudre.
Si votre source utilise pgvector, postgis ou autres, installez-les sur Lampion avant le restore via la console (Settings → Extensions) ou l'API.
$ curl -X POST -H "Authorization: Bearer $TOKEN" \ -d '{"name":"pgvector"}' \ api.lampion.cloud/v1/projects/{id}/endpoints/{eid}/extensions
Toujours utiliser --no-owner --no-privileges au dump ET au restore. Si vous avez besoin de rôles applicatifs spécifiques, créez-les après le restore via la section Roles de la console ou l'API.
Si vous avez fait un dump puis des écritures sur la source avant la coupure, les séquences peuvent être en retard. Resynchronisez-les après le switch :
SELECT setval(pg_get_serial_sequence('users', 'id'), (SELECT MAX(id) FROM users));
Pour les très grosses bases : (1) resize le compute Lampion à 8 CU avant le restore, (2) utilisez --jobs=8, (3) dumpez par schéma ou par table si possible pour pouvoir reprendre en cas d'échec, (4) ouvrez un ticket support avant la migration pour bénéficier d'un accompagnement.
Lampion impose TLS 1.3 sur toutes les connexions. Ajoutez toujours ?sslmode=require à la fin de la connection string si votre client ne le fait pas automatiquement.
Lampion utilise UTF8 et la collation en_US.utf8 par défaut. Si votre source utilise une collation différente, créez la base manuellement avec la bonne collation avant le restore.
Prêt à migrer ?
Créez votre compte, créez un projet, et lancez votre premier pg_restore.