ClickHouse 成立研究部門 ClickHouse Labs，延攬 CMU 教授 Andy Pavlo 出任資料庫研究副總裁
ClickHouse Blog · 2026-08-03
ClickHouse 於 2026-08-03 宣布成立新的研究部門 ClickHouse Labs，由卡內基美隆大學（CMU）教授 Andy Pavlo 出任副總裁一職，全職帶領這個新單位。這是 ClickHouse 首次成立獨立的研究組織，鎖定分析型資料庫與 PostgreSQL 的基礎研究。公司同時發布了兩篇公告，分別說明 Pavlo 的背景與 ClickHouse Labs 的職掌。
背景
Andy Pavlo 自 2013 年起在 CMU 電腦科學系擔任教授，並帶領校內的資料庫研究小組，目前是具終身職（Indefinite Tenure）的副教授。他的研究領域涵蓋自治資料庫（autonomous databases）、交易處理（transaction processing）與大規模分析系統，曾獲頒 IEEE TCDE Ramez Elmasri Award、VLDB Early Career Award、NSF CAREER Award 與 ACM SIGMOD Jim Gray Best Dissertation Award 等獎項。他也共同創辦了將機器學習應用在資料庫參數調校上的新創公司 OtterTune。
除了學術研究，Pavlo 長年維護資料庫系統目錄網站 DBDB.io，追蹤記錄業界與學界的資料庫系統演進，並在自己開的資料庫課程教材中納入 ClickHouse 的內容——這也是他與 ClickHouse 團隊早有接觸的背景之一。
職掌與方向
Pavlo 在 ClickHouse 的職稱是 VP of Database Research，任務是建立並帶領 ClickHouse Labs。根據公告，這個研究單位會與 ClickHouse 的工程團隊、客戶及業界夥伴密切合作，同時也會和公司內部的 PostgreSQL 團隊協作，同步推進交易型與分析型資料庫的能力。Pavlo 在公告中表示：「最令人興奮的資料庫研究不只是在論文裡描述一個新想法，而是透過打造與測試真正的系統，證明這個想法真的可行。」
公告列出的具體研究方向包含：
- 加速把工程團隊既有的最佳化構想驗證並落地到正式產品中
- 研究 AI 與 agentic 技術如何與 ClickHouse、PostgreSQL 這類資料庫系統互動
- 探索新的硬體、演算法、資料結構與執行策略，以及資料庫開發方式本身的演進
- 把即時分析、資料倉儲與可觀測性系統放進真實世界的高負載場景中驗證，並把成果投稿到主要學術會議
Pavlo 也提到，ClickHouse Labs 的目標是「做出具有科學價值的研究，再協助把最好的想法轉化成對使用者真正重要的技術」，並將這個模式類比為 Google 過去把基礎研究轉化為改變產業之技術的做法。
原始來源：ClickHouse Labs founding announcement、Andy Pavlo joins ClickHouse
ClickHouse 打造沙盒平台，讓 110 套資料庫系統可以直接連進去互相比較效能
ClickHouse Blog · 2026-08-03
ClickHouse 工程團隊於 2026-08-03 發布文章，介紹他們建置的 ClickBench Playground，這是一個可以直接在瀏覽器裡對 110 套不同資料庫系統下查詢的線上服務，網址為 benchmark.clickhouse.com/playground。每套系統都預先載入了一億筆記錄的資料集，使用者無需自行安裝任何一套系統就能實際操作。
什麼是 ClickBench
ClickBench 是 ClickHouse 在 2013 年建立的開放效能測試基準，最初只是用來測試 ClickHouse 自身在分析型查詢上的表現。到了 2022 年，這個基準被擴充成一個開放給所有分析型資料庫比較的公開榜單，任何廠商或個人都可以送出自己系統跑出的測試結果，讓不同資料庫的查詢效能可以放在同一份榜單上比較。
Playground 能做什麼
過去 ClickBench 只能看到排行榜上的數字，這次的 Playground 則讓使用者可以直接連進 110 套系統各自的即時環境，親手下查詢、建立資料表與資料庫、insert 資料、drop table 等操作。使用者可以：
- 對同一份資料集在不同系統上執行相同查詢，直接比較回傳結果與執行時間
- 啟動類似「競賽」模式，讓多套系統同時跑同一組查詢，並排比較
- 嘗試各系統原生的查詢語法，範圍涵蓋 Pandas、Polars、DuckDB 這類嵌入式系統，甚至包含 BQN 這種少見的陣列語言系統
這 110 套系統橫跨傳統關聯式資料庫、分析型資料庫、嵌入式資料處理函式庫，也刻意收錄了一些非主流甚至實驗性質的系統，讓使用者能一次比較的範圍不侷限在主流選項。
技術架構
要讓 110 套系統同時存在又不互相干擾，ClickHouse 團隊把整個 Playground 架在 AWS 的 metal 機器上，並用 Firecracker 虛擬機器隔離每一個訪客的工作階段。儲存端使用 XFS 檔案系統搭配壓縮與 reflink，再疊上 BtrFS 壓縮，才把一百多套系統的資料塞進 7.5TB 的儲存空間裡。
每套系統開機都是從快照（snapshot）還原，冷啟動時間壓在 5 秒以內；對外連線則透過 NAT 與 proxy，並設有白名單過濾訪客虛擬機器能連到的網路位置，同時搭配自動化的 CPU／記憶體限制與看門狗（watchdog）行程，避免單一使用者的查詢拖垮整個平台。
原始來源：ClickHouse Blog
PlanetScale 用 per-shard 平行備份，把 32TB Postgres 的備份時間從 22 小時壓到 42 分鐘
PlanetScale Blog · 2026-07-31
PlanetScale 工程團隊發布文章，說明他們如何解決已分片（sharded）的 Postgres 叢集在備份時遇到的單機頻寬瓶頸。他們的做法是讓每個分片各自用獨立的 EC2 機器平行備份，而不是把所有資料擠在同一條管線裡搬運。
原本的問題
傳統的 Postgres 備份是在單一實例上執行，把整個資料庫內容搬到單一台備份機器上。以一個 32TB 的資料庫為例，壓縮後大約還剩 20TB，如果要以每秒 500MB 的速度搬運將近 40TB 的資料量，得花上約 22 小時。這個時間已經逼近一整天，意味著若想一天備份兩次，前後兩次備份工作幾乎會頭尾相接，完全沒有緩衝空間。問題的根源不在硬碟或壓縮率，而是單一節點的網路頻寬就是搬運速度的天花板，加再多運算資源也繞不開這條單一路徑。
採用的方法
PlanetScale 的做法是利用資料庫本身已有的 sharding 架構，替每個分片各自開一台全新的 EC2 機器來專門處理備份工作。每個分片的備份節點各自獨立執行以下流程：
- 從 S3 還原上一次的備份內容
- 以混合方式重放 WAL（Write-Ahead Log）：先套用存放在 S3 上的 WAL 歸檔紀錄，再從 primary 節點取得最新變更，兩者合併補到最新狀態
- 把備份完的內容加密後再上傳回 S3
文章提到實際負責 WAL 歸檔與續傳的工具是 wal-g，並將 archive_timeout 設為 5 分鐘，避免 WAL 歸檔檔案累積過久；還原初始資料則沿用 Postgres 內建的 pg_basebackup。因為每個分片各自處理自己的那一份資料，原本卡在單一節點的頻寬瓶頸就被拆成多條平行路徑，整體吞吐量會隨分片數量往上疊加。
實際效果
同樣以 32TB 的資料庫為例，切成 8 個分片平行備份後，時間從單機的約 22 小時降到約 2.8 小時；若切成 32 個分片，時間可以壓到 42 分鐘。文章也提到，把資料規模放大到 100TB、分片數增加到 100 個，整體吞吐量仍能維持在跟單一分片備份 1TB 資料差不多的水準，顯示這個做法的擴展性接近線性，多分片情況下整體備份速度可以超過每秒 50GB。
原始來源：PlanetScale Blog