NVMe 讓 Postgres 吞吐衝高，但分析天花板沒被打破
ClickHouse 官方部落格 · 2026-09-21
本地 NVMe 把 Postgres 的交易吞吐拉到 EBS gp3 的 9.2 倍，但分析查詢的天花板沒有跟著打開，因為對十億行等級的資料做聚合仍然得整頁掃描。這是 ClickHouse 官方部落格於 2026 年 9 月 21 日發布的基準測試，作者是 ClickHouse Postgres 工程總監 Kaushik Iska，讀者要留意這篇文章最終是在替「把資料 CDC 到 ClickHouse」這個方案背書。
原本的問題
過去業界的預設分工是OLTP 留在 Postgres、分析查詢另外搬去獨立 OLAP 引擎，理由是雲端硬碟延遲太高，連交易寫入本身都會撞到 I/O 天花板。ClickHouse 這次想驗證的問題是：如果把儲存換成本地 NVMe，Postgres 的效能天花板是不是就此整個改變，讓團隊不再需要導入額外的分析引擎。測試因此把同一台機器分別接上 NVMe 與 EBS gp3（3,000 IOPS 基準值），在完全相同的資料量與負載下量出兩者差距。
採用的方法
基準測試跑在一台 m6id.4xlarge（16 vCPU、64 GiB 記憶體）的執行個體上，Postgres 版本為 18.3 原始碼編譯，shared_buffers 設為 16 GB 並開啟 checksum。資料量用 pgbench scale factor 33,000 撐出 482 GiB 的 heap、33 億筆資料列，確保資料集遠大於記憶體與快取。壓測用 64 個 client 跑在 16 個 thread 上持續五分鐘，每筆交易隨機更新整張表中的任一列，並用 Parca 搭配 eBPF 做連續 profiling、以 1 Hz 取樣 pg_stat_activity。
實際效果
結果顯示 NVMe 在交易與維運兩個面向都明顯把天花板往上推。
| 指標 | NVMe | EBS gp3 |
|---|---|---|
| TPS（中位數） | 16,030 | 1,734 |
| 單筆 UPDATE 延遲 | 4.0 ms | 36.9 ms |
| VACUUM 清 10 GB bloat | 366 s | 964 s |
| Logical decoding 吞吐（約 10 GB slot） | 89 MB/s | 52 MB/s |
換算下來 NVMe 的交易吞吐是 EBS 的 9.2 倍，VACUUM 清理速度快 2.6 倍，這些都是實打實的交易與維運改善。但作者自己下的結論是「更快的硬碟拉高了天花板，卻沒有改變形狀」：對十億行等級的資料做聚合，Postgres 仍然得逐頁掃描整張表，NVMe 只是讓每一頁讀得更快，不會讓查詢邏輯從全表掃描變成欄式跳讀。
這推翻的認知是「只要換上夠快的 SSD，Postgres 就能自己扛住分析查詢」，測試證明硬體升級解決的是交易延遲與維運耗時，不是分析查詢的演算法瓶頸。對正在猶豫要不要導入獨立 OLAP 引擎的資料工程團隊來說，該檢查的不是 SSD 夠不夠快，而是幾個具體訊號：分析查詢是否經常掃描超過 shared_buffers（本例為 16 GB）範圍的資料表、VACUUM 與logical decoding的延遲是否隨資料量持續累積、以及聚合查詢的對象是否已經逼近整張表等級的列數。ClickHouse 文章給的建議路線是讓 Postgres 繼續處理交易寫入，再用 CDC 把每筆 insert、update、delete 串流進 ClickHouse 做分析，但這個結論同時也是這篇文章的商業立場，團隊評估時應該把它當成論點而非中立測試報告來讀。