即時分析的真實代價：ClickHouse Cloud 對決 Snowflake 全路徑基準測試
ClickHouse Blog · 2026-06-23
ClickHouse 團隊於 2026 年 6 月 23 日發布了名為 CostBench 的開源基準測試結果，針對即時分析場景對 ClickHouse Cloud 與 Snowflake（含標準表格與 Interactive Tables 兩種配置）進行了端對端的成本效能評比。測試模擬持續以每秒百萬筆的速率寫入股票報價資料，並在寫入期間同步執行儀表板查詢與原始資料鑽取，完整還原生產環境的工作負載型態。這是目前同類測試中少數將「寫入成本」與「查詢成本」合併計算的公開基準。
背景
傳統基準測試往往只測量單一維度——例如查詢速度或壓縮率——卻忽略了在真實業務場景中，寫入、資料維護與查詢三者必須同時進行的事實。CostBench 的設計出發點正是要彌補這個缺口：它模擬一個完整的資料管線，包含持續寫入、物化視圖的即時維護，以及不間斷的查詢負載。測試資料集採用來自 Massive.com 的真實股票報價（NBBO 格式），共約 1,130 億筆資料、壓縮後約 651 GB，分布在 232 個 Parquet 日檔中。
三個受測系統在硬體配置上盡量拉平：ClickHouse Cloud 寫入端使用 2 個 2 vCPU/8 GB 節點，查詢端約 16 vCPU；Snowflake 標準寫入使用 Gen2 X-Small（8 vCPU/16 GB），Interactive Tables 額外需要一個 Gen2 X-Large 倉庫持續執行刷新；Databricks 使用 2X-Small Warehouse（8 vCPU/61 GB）。所有系統以完全相同的 1M rows/sec 寫入速率運行。
核心改動
CostBench 將整個分析管線拆解為四個可量測的子路徑：持續寫入（continuous ingest）、原始資料的物理排序維護、物化視圖的預聚合維護，以及查詢服務。儀表板查詢每 10 分鐘執行一次，鑽取查詢每小時執行一次，兩者均在資料持續寫入期間同步執行，而非等寫入完成後才開始測量。
Snowflake 的 Interactive Tables 是該公司針對即時分析場景推出的較新產品，透過將物化視圖的維護成本轉移至獨立倉庫，換取更低的查詢延遲與更短的資料新鮮度落差。這使得它在部分指標上優於 Snowflake 標準配置，但也大幅拉高了基礎設施費用。
規格細節
在 28 小時的完整測試中，延遲與新鮮度的表現如下：
| 指標 | ClickHouse Cloud | Snowflake 標準 | Snowflake Interactive Tables |
|---|---|---|---|
| 儀表板查詢延遲 | 個位數毫秒（全程平穩） | 低秒到數十秒（波動大） | 改善，但隨資料量上升 |
| 物化視圖落差 | 同步（無落差） | 最大 60–72 分鐘 | 約 1 分鐘 |
| 28 小時寫入成本 | $21.86 | $286.58（約 13×） | $1,927.80（約 88×） |
| 查詢運算成本 | $0.061 | $11.288（約 185×） | $0.144（約 2.4×） |
鑽取查詢（drill-down queries）的延遲表現隨資料量成長而分化：ClickHouse 維持大致平穩；Snowflake 標準配置在 1,000 億筆時延遲已達數秒；Interactive Tables 有所改善，但仍呈上升趨勢。
影響範圍
綜合成本與查詢時間的效能指數顯示，ClickHouse 相較 Snowflake 標準配置效能高出約 969 倍，相較 Interactive Tables 則高出約 180 倍。Interactive Tables 雖以大幅提高的基礎設施費用換來了更好的查詢表現，但整體成本效益仍遠不及 ClickHouse。
值得注意的是，CostBench 為 ClickHouse 自行開發並公開的基準工具，測試配置與定價假設均可在 GitHub 上查閱，社群可提交改善配置的 Pull Request，Snowflake 亦已發表回應部落格。資料集版權由 Massive.com 持有，不可再散布，但測試程式碼與方法論均已公開，允許獨立重現。
原始來源：ClickHouse Blog — CostBench Benchmark、CostBench GitHub Repository
pg_clickhouse v0.3.2：Postgres 19 相容、TLS 精細控制與記憶體洩漏修正
ClickHouse Blog · 2026-06-23
ClickHouse 官方於 2026 年 6 月 23 日詳述了 pg_clickhouse v0.3.2 的功能更新，這個讓 PostgreSQL 直接查詢 ClickHouse 資料的外部資料包裝器（Foreign Data Wrapper，FDW）擴充套件在最新版本中帶來了四項主要改動：Postgres 19 beta1 相容性、更細緻的 TLS 連線控制、修正正規表達式標誌映射，以及解決兩個記憶體消耗缺陷。此版本為純 binary 更新，現有 v0.3.x 安裝無需執行 ALTER EXTENSION UPDATE 即可取得所有改善。
背景
pg_clickhouse 讓使用者能夠在 PostgreSQL 查詢介面中直接存取 ClickHouse 的分析能力，適用於同時運行兩套系統的工程團隊。透過 Postgres 的 FDW 機制，應用程式毋須修改連線邏輯，即可將計算密集的分析查詢下推（pushdown）至 ClickHouse 執行，同時保留 Postgres 的事務性操作與權限體系。該專案的 v0.3.2 發布於 GitHub，作者為 David Wheeler。
Postgres 19 預計於 2026 年秋季正式發布，beta1 已於近期釋出供社群測試。pg_clickhouse 為了支援新版本，針對 tuple/array 最佳化路徑進行了程式碼調整，並更新了相關標頭檔引用，確保與新版 Postgres 內部 API 的相容性。
核心改動
TLS 控制部分新增了兩個 CREATE SERVER 選項。舊版本以啟發式方法（heuristic）推測 TLS 狀態，例如透過連接埠號碼判斷是否應啟用加密，在 ClickHouse Cloud 等預設啟用 TLS 的環境中容易造成混淆。新選項讓意圖明確：
secure：接受on（強制 TLS）、off（明文）或auto（依雲端環境自動判斷，為預設值）min_tls_version：指定最低協議版本，從 TLSv1 到 TLSv1.3 可選compression：二進制驅動新增結果壓縮，支援none、lz4（預設）或zstd
-- 建立帶有 TLS 與壓縮設定的伺服器連線範例
CREATE SERVER my_clickhouse
FOREIGN DATA WRAPPER clickhouse_fdw
OPTIONS (
host 'clickhouse.example.com',
port '9440',
secure 'on',
min_tls_version 'TLSv1.2',
compression 'lz4'
);規格細節
正規表達式的修正針對 Postgres（使用 POSIX regex）與 ClickHouse（使用 RE2 語法）兩套實作之間的標誌映射差異進行了校正。具體問題在於大小寫不敏感（case-insensitive）與換行處理（newline handling）等旗標在跨平台轉換時會產生語義落差，導致相同的 SQL 在兩套資料庫上返回不同結果。此版本校正了映射邏輯，並擴展了 regexp_match() 的下推支援，涵蓋非捕獲群組（non-capturing groups）。
記憶體問題的修正分為兩個獨立場景：一是 HTTP 驅動在未緩衝查詢時的記憶體洩漏，二是在巢狀迴圈 join（nested-loop join）中對同一外部資料表重複掃描所引發的記憶體消耗累積。兩個問題均已在此版本中解決，對於頻繁執行跨資料庫 join 的場景影響尤為顯著。
影響範圍
此版本為純 binary 更新（binary-only release），代表已安裝 v0.3.x 的使用者在重新載入擴充套件後即可獲得所有改善，無需修改 schema 或重建外部資料表定義。對於計畫升級至 Postgres 19 的團隊，pg_clickhouse 已率先提供 beta1 相容支援，正式版的完整測試將在 Postgres 19 GA 後進行。
原始來源：ClickHouse Blog — pg_clickhouse v0.3.2、GitHub Release v0.3.2