Managed Postgres 数据迁移

比较迁移到 ClickHouse Managed Postgres 的四种路径，选择最符合源数据库和停机要求的方案。

你可以通过四种不同的方式迁移到 Managed Postgres。具体选择哪一种， 取决于你是否需要持续复制 (CDC (变更数据捕获) ) 、迁移来源，以及应用在切换期间 可容忍的停机时长。

方法	持续复制 (CDC (变更数据捕获) )	运行位置	最适合
ClickPipes	是	ClickHouse Cloud 控制台	适用于大多数迁移——提供开箱即用的引导式向导，支持初始加载和 CDC (变更数据捕获)
PeerDB	是	自托管 (Docker)	适用于 ClickPipes UI 未覆盖的来源或工作流
pg_dump 和 pg_restore	否	本地机器	适合小型或静态数据集的一次性迁移，且可以接受停机时间
逻辑复制	是	源端和目标端 Postgres	适合希望直接控制原生 Postgres 复制且不依赖第三方工具的场景

​

ClickPipes

ClickPipes 是大多数迁移场景的推荐 方案。它完全在 ClickHouse Cloud 控制台中运行， 并引导你完成连接源端、导出和导入 schema，以及启动有或没有 CDC (变更数据捕获) 的初始加载。预置的源 连接器支持 Amazon RDS、Aurora、Supabase、Google Cloud SQL、Azure Flexible Server、Neon、Crunchy Bridge、TimescaleDB，以及任何通用的 Postgres 实例。

​

PeerDB

PeerDB 是一款通过 Docker 运行的自托管迁移 工具。当源端或工作流不适合使用 ClickPipes 向导时，请使用它——例如，当你需要通过脚本在多个数据库中创建 peer，或将整个迁移过程完全放在自己的网络内运行时。 PeerDB 不会自动迁移索引、约束或触发器；数据迁移到目标端后， 你需要在目标端重新创建它们。

​

pg_dump 和 pg_restore

pg_dump 和 pg_restore 会获取源端的快照，并在目标端回放。由于没有持续的 复制，因此在转储和恢复期间，必须停止源端上的写入。 对于小型或静态数据集，或者可以接受维护窗口的非生产环境， 这是更合适的选择。

​

逻辑复制

逻辑复制 使用 Postgres 原生的 publication 和订阅，将变更从 源端流式传输到目标端。你需要自行配置 wal_level、replication slots，以及 REPLICATION 权限——整个过程中不会有任何第三方工具介入。 如果你希望完全掌控复制机制，或者你的环境不允许使用外部迁移工具，请选择这种方式。

​

迁移后

数据开始迁移后，使用数据验证 在切换应用流量之前确认源端与目标端的行数和内容是否一致。迁移 FAQ 介绍了常见错误及恢复步骤。

​

从 Supabase 迁移

如果您正从 Supabase 迁移，请参阅 Supabase 到 Managed Postgres 的迁移指南，了解详细的分步操作说明。