Skip to main content
ClickHouse Managed Postgres inclut ClickPipes, qui offre une voie de migration en ligne entièrement gérée depuis Neon. Le service migre automatiquement le schéma, effectue un chargement initial optimisé grâce au snapshot parallèle et s’appuie sur le Change Data Capture (CDC) pour maintenir les deux bases de données synchronisées jusqu’au basculement. Avec ClickPipes, les clients peuvent migrer des bases de données Postgres de plusieurs téraoctets en quelques heures seulement.
1

Préparer Neon

Créez un utilisateur ClickPipes dédié disposant des permissions de lecture et de réplication :
Exécutez ces étapes sur votre branche Neon de production, en répétant les grants pour chaque schéma que vous souhaitez migrer. Chaque table répliquée doit posséder une primary key ou utiliser REPLICA IDENTITY FULL.Dans la console Neon, accédez à Settings → Logical Replication et activez la logical replication. Si vous utilisez des restrictions d’IP, autorisez les adresses IP statiques de ClickPipes. Consultez le guide de configuration de la source Neon pour des instructions détaillées.
2

Migrer et basculer avec ClickPipes

Suivez le guide de migration ClickPipes pour configurer et mener à bien la migration. ClickPipes automatise le processus de bout en bout :
  • Migration du schéma source vers une target database vide.
  • Chargement initial optimisé grâce au snapshot parallèle.
  • Utilisation du CDC pour maintenir la cible synchronisée avec Neon.
  • Monitoring de la progression, du replication lag et des erreurs.
  • Accompagnement tout au long de la validation et du basculement.
Une fois le chargement initial terminé et le replication lag proche de zéro, effectuez le basculement à l’aide de l’onglet guidé Post-migration steps dans la vue de détail du ClickPipe. Consultez Basculer le trafic pour la procédure complète. L’assistant vous guide, dans l’ordre :
  1. Passez Neon en mode lecture seule pour arrêter les écritures.
  2. Vérifiez la concordance du nombre de lignes entre la source et la cible.
  3. Mettez le pipe en pause.
  4. Réinitialisez les séquences sur la cible.
  5. Basculez le trafic en mettant à jour la connection string de l’application pour qu’elle pointe vers ClickHouse Managed Postgres.
  6. Nettoyez en supprimant le replication slot et le ClickPipe.
Gardez Neon disponible en mode lecture seule pendant une courte période, au cas où un retour en arrière serait nécessaire. Une fois le nouvel environnement stabilisé, effectuez l’étape de nettoyage pour supprimer le ClickPipe et son replication slot.

​
Points à considérer pour la migration

​
Branches

Neon propose une création de branches instantanée en copy-on-write. ClickHouse Managed Postgres s’appuie sur du stockage NVMe local pour offrir des performances Postgres rapides, prévisibles et fiables. En contrepartie, les branches ne sont pas instantanées : elles sont créées sous forme de deployments indépendants via la récupération à un instant précis (PITR). Elles sont généralement disponibles en quelques minutes. Pour le développement au quotidien, nous recommandons de maintenir une base de données de développement ClickHouse Managed Postgres de taille réduite, contenant des données de production représentatives et anonymisées — quelques gigaoctets par exemple — et d’en créer des branches PITR selon les besoins. La création et le nettoyage des branches peuvent être automatisés au moyen de clickhousectl, notre CLI officielle, ou via OpenAPI ou Terraform Certains clients recourent à cette approche pour gérer des centaines d’environnements de développement. Nous améliorons activement l’expérience de fork et de sandbox. Consultez la documentation sur la création de branches.

​
Neon Serverless Driver

Si votre application n’utilise pas le Neon Serverless Driver, vous pouvez ignorer cette section. Les applications exécutées sur des plateformes telles que Vercel peuvent utiliser le Neon Serverless Driver, qui repose sur WebSocket et est spécifique à Neon. Il ne suffit pas de le faire pointer vers ClickHouse Managed Postgres. Avant la migration :
  • Vérifiez la présence de dépendances telles que @neondatabase/serverless. Le cas échéant, remplacez-les par un driver Postgres standard comme node-postgres (pg).
  • Pour les workloads serverless qui créent de nombreuses connexions de courte durée, utilisez l’instance PgBouncer intégrée.
  • Les prepared statements sont pris en charge. Toutefois, comme PgBouncer utilise un pool de connexions par transaction, validez les applications qui s’appuient sur un comportement au niveau de la session, ce qui reste peu courant :
    1. Utilisez SET LOCAL plutôt que SET ou RESET au niveau de la session.
    2. Utilisez des temporary tables limitées à la transaction avec ON COMMIT DROP.
    3. NOTIFY est pris en charge ; LISTEN ne l’est pas.
    4. Utilisez des verrous consultatifs au niveau de la transaction, et non au niveau de la session.
    5. Les curseurs limités à la transaction sont pris en charge ; WITH HOLD ne l’est pas.
  • Si votre application dépend d’un comportement au niveau de la session non pris en charge, connectez-vous directement à Postgres plutôt que de passer par PgBouncer.
Pour plus de détails, consultez la compatibility matrix de PgBouncer.

​
Limites de connexions

ClickHouse Managed Postgres prend en charge par défaut 500 connexions Postgres directes. Si votre workload Neon dépasse ce nombre, vous pouvez :
  • Utiliser un pool de connexions côté application.
  • Utiliser l’instance PgBouncer intégrée, qui prend en charge jusqu’à 5 000 connexions client.
  • Augmenter max_connections si davantage de connexions directes sont nécessaires.
    • max_connections peut être modifié depuis Settings → Edit parameters. Certaines modifications nécessitent un redémarrage. Consultez la documentation de configuration.

​
Modifications de schéma pendant la migration

Réduisez au maximum la période entre le démarrage de ClickPipes et le basculement — idéalement quelques jours tout au plus — et évitez toute modification de schéma pendant cet intervalle. Certains clients maintiennent des environnements en parallèle pendant plusieurs jours, le temps de tester leurs applications avec ClickHouse Managed Postgres. Une fois les tests terminés, ils démarrent un nouveau ClickPipe pour la migration finale, ce qui réduit le délai entre le chargement initial et le basculement. Le CDC réplique les inserts, les updates, les deletes et ADD COLUMN, mais la plupart des autres modifications DDL ne sont pas propagées. Cela concerne notamment les index, les triggers, les modifications d’enum, les constraints, les fonctions et la plupart des modifications de colonnes. Certaines modifications, comme une valeur d’enum manquante, interrompent la réplication et apparaissent dans les logs ClickPipes. Appliquez la modification manquante sur la cible : la réplication devrait alors reprendre. D’autres modifications, comme un index ou un trigger nouvellement créé, n’interrompent pas nécessairement le CDC, mais doivent tout de même être créées manuellement avant le basculement. Avant de rediriger le trafic, comparez les schémas source et cible, appliquez les objets manquants et réinitialisez les sequences. La FAQ sur la migration présente les erreurs courantes et les actions correctives.
Dernière modification le 26 septembre 2026