2026-10-09 — Clera 用 ClickPipes 一夜遷移 500 GB Postgres

Clera 用 ClickPipes 一夜把 500 GB Postgres 遷到 ClickHouse Managed Postgres

ClickHouse Blog（Clera CTO Daniel Wintermeyer 客座文章） · 2026-10-08

Clera 沒有停機搬家，而是在正式流量照常寫入時，用 ClickPipes 把超過 500 個資料表、500 GB 以上的 Postgres 複製到新服務，隔天清晨完成切換。目的不是換資料庫引擎，而是把原廠商上網路儲存的 IOPS 瓶頸換成本機 NVMe 上的原生 Postgres。

Clera 是 AI 人才媒合服務，文章稱資料量在遷移時超過 500 GB（現在接近 1 TB）。以下整理它的瓶頸、遷移流程，以及官方文件列出的限制。

原本的問題

文章說，原廠商的資料庫曾連續六天 CPU 100%，本應即時的候選人查詢要約三秒，嚴重時連用主鍵都寫不進更新。

Clera 把負載分成三類：熱讀取（職缺列表、materialized view）、主鍵點查詢、背景工作（重分析與 SEO materialized view 重新整理）。背景查詢會擋住點查詢，爬蟲突發流量又加重 IOPS 與 CPU 壓力。

選型：先用正式流量重播

團隊評估 Supabase、Neon、PlanetScale 與 ClickHouse Managed Postgres。第一輪把約 500 GB 載入四家，重播正式查詢，比較 QPS、P99 延遲與錯誤率。ClickHouse 幾乎全面勝出，差距最大的是 IOPS，Supabase 與 Neon 因此出局。

第二輪用 sysbench TPC-C（作者註明並非完整符合 TPC-C）對 PlanetScale 與 ClickHouse 各跑 8 到 128 條執行緒。ClickHouse 預設設定下的吞吐優勢在 128 條時約 16%，16 條時約 42%。作者引用 Ubicloud 的比較文章解釋原因：本機 NVMe 對上網路儲存。基準測試腳本與結果放在 getclera/ps-vs-ch-benchmark。

遷移方法

工具是 ClickPipes，跑兩條平行管線：一條核心資料，一條非必要資料。官方文件把流程分成「初始載入加 CDC」，也就是先複製既有資料，再持續同步變更。

• 前置：調整來源端 WAL 保留設定、啟用 publication、檢查主鍵與 extension。作者說 extension 不相容最麻煩，工程師花了數天改系統繞過。
• 複製：500 多張表從 EU 搬到 US，期間正式流量照舊。測試時遇到 EU 延遲與表量組合造成的問題，ClickHouse 工程師當晚 11 點送出修補 PR。
• 收尾：還原 trigger、重建索引、重設 sequence，做資料一致性檢查後，重新部署整個系統指向新資料庫。

因為 schema 經常變動，團隊要在新副本建立後立刻切換，避免舊庫 schema 再變。文章未量化實際停機時間。

影響範圍

想照做的團隊先看官方文件的限制：CDC 只傳遞 DML 與 ADD COLUMN，DROP COLUMN 與 ALTER COLUMN 要在目標端手動套用。自動 schema 模式要求目標為空庫。

文件的切換步驟是先把來源設為唯讀，再驗證列數、暫停 pipe、重設 sequence、切換連線字串：

ALTER DATABASE "<source_db>" SET default_transaction_read_only = on;
-- 驗證列數、暫停 ClickPipe、重設 sequence
-- 應用程式改連 Managed Postgres
SELECT pg_drop_replication_slot('<slot_name>');

文件的唯讀步驟與 Clera 的「正式流量不中斷」說法有落差，作者未說明他們是否採用該步驟。文件也提到大表的列數驗證可能只是近似值。

實際效果

要注意：Clera 搬的是 vanilla Postgres，不是 ClickHouse 分析資料庫；文章說之後需要時可再同步到 ClickHouse。

原始來源：ClickHouse Blog、ClickPipes 遷移文件、Ubicloud 本機與網路儲存比較