Migration de données Managed Postgres

Comparez les quatre options de migration vers ClickHouse Managed Postgres et choisissez celle qui correspond à votre base de données source et à vos contraintes de temps d’arrêt.

Vous pouvez migrer vers Managed Postgres selon quatre approches différentes. Le choix dépend de votre besoin de réplication continue, de la source à partir de laquelle vous migrez et du temps d’indisponibilité que votre application peut tolérer pendant la bascule.

Méthode	Réplication continue (CDC)	Où il s’exécute	Idéal pour
ClickPipes	Oui	console ClickHouse Cloud	La plupart des migrations — assistant guidé avec chargement initial et CDC prêts à l’emploi
PeerDB	Oui	Self-hosted (Docker)	Sources ou workflows non pris en charge par la ClickPipes UI
pg_dump and pg_restore	Non	Votre machine locale	Migrations ponctuelles de petits datasets ou de datasets statiques lorsque l’indisponibilité est acceptable
réplication logique	Oui	Postgres source et cible	Contrôle direct de la réplication Postgres native, sans outil tiers

​

ClickPipes

ClickPipes est la solution recommandée pour la plupart des migrations. Il s’exécute entièrement dans la console ClickHouse Cloud et vous guide pour vous connecter à la source, exporter et importer le schéma, puis lancer un chargement initial avec ou sans CDC. Des connecteurs source préconfigurés prennent en charge Amazon RDS, Aurora, Supabase, Google Cloud SQL, Azure Flexible Server, Neon, Crunchy Bridge, TimescaleDB, ainsi que toute instance Postgres générique.

​

PeerDB

PeerDB est un outil de migration auto-hébergé que vous exécutez via Docker. Utilisez-le lorsque votre source ou votre workflow ne se prête pas à l’assistant ClickPipes — par exemple, lorsque vous devez automatiser par script la création de peers sur de nombreuses bases de données ou exécuter la migration entièrement au sein de votre propre réseau. PeerDB ne migre pas automatiquement les index, les contraintes ni les déclencheurs ; vous les recréez sur la cible une fois les données chargées.

​

pg_dump and pg_restore

pg_dump and pg_restore créent un instantané de la source et le restaurent sur la cible. Il n’y a pas de réplication continue, les écritures doivent donc être interrompues sur la source pendant toute la durée de l’export et de la restauration. C’est le bon choix pour de petits jeux de données ou des jeux de données statiques, ou pour des environnements hors production où une fenêtre de maintenance est acceptable.

​

Réplication logique

La réplication logique utilise les publications et abonnements natifs de Postgres pour transmettre les modifications de la source vers la cible. Vous configurez vous-même wal_level, les slots de réplication et le privilège REPLICATION — aucun outil tiers ne s’interpose. Choisissez cette option si vous souhaitez garder un contrôle total sur les mécanismes de réplication ou si votre environnement ne permet pas l’utilisation d’outils de migration externes.

​

Après la migration

Une fois le transfert des données lancé, utilisez la validation des données pour vérifier que le nombre de lignes et le contenu correspondent entre la source et la cible avant de basculer le trafic de l’application. La FAQ des migrations présente les erreurs courantes et les étapes de reprise.

​

Migrer depuis Supabase

Si vous migrez depuis Supabase, consultez le guide de migration de Supabase vers Managed Postgres pour obtenir des instructions détaillées, étape par étape.