Set up docs MCPVous pouvez migrer vers ClickHouse 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 | auto-hébergé (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 ClickHouse Managed Postgres pour obtenir des instructions détaillées, étape par étape.