PostgresBench 實測：高可用性設定讓 Managed Postgres 效能打了多少折
ClickHouse Blog · 2026-07-21
ClickHouse 發布開源基準測試工具 PostgresBench，鎖定同時打出「零資料遺失」與「主節點故障後 2 分鐘內恢復」承諾的 Managed Postgres 服務，實際量測啟用高可用性（HA）後對效能造成的衝擊。受測對象涵蓋 ClickHouse Managed Postgres、AWS RDS、AWS Aurora、Crunchy Bridge 與 Neon。所有案例都在同規格硬體上跑同一套負載，藉此比較不同 HA 架構的代價。
兩種 HA 架構
受測服務可分成兩類。Shared-Nothing 架構（ClickHouse、RDS、Crunchy Bridge）仰賴原生 PostgreSQL 串流複寫，搭配實體 standby 節點與自動 failover，測試中分別涵蓋 1 個非同步 standby，以及 2 個同步 standby 的 quorum 設定。Shared-Storage 架構（Aurora、Neon）則把運算與儲存層分離，靠儲存層的多份 WAL 複本保證持久性，不需要傳統的串流複寫節點。
測試方法
每組測試使用 16 vCPU、64 GB RAM 的執行個體，資料集大小為 500 GB，每次跑 10 分鐘，記錄三項指標：平均 TPS（每秒交易數）、p99 latency 與平均延遲。這三項指標同時涵蓋吞吐量與尾端延遲，用意是呈現 HA 機制在正常運作（非故障切換）期間對日常寫入路徑造成的穩態負擔。
結果數據
| 服務 | HA 設定 | 平均 TPS | p99 延遲 |
|---|---|---|---|
| ClickHouse Managed Postgres | 1 個非同步 standby | 24,667 | 24.17 ms |
| ClickHouse Managed Postgres | 2 個同步 standby | 20,720 | 33.49 ms |
| Crunchy Bridge | HA（1 非同步） | 11,135 | 41.89 ms |
| AWS RDS | Multi-AZ cluster（2 同步） | 4,659 | 816.63 ms |
| AWS Aurora | HA（1 standby） | 9,520 | 39.92 ms |
| Neon | 單節點 | 7,802 | 56.30 ms |
以同樣訴求「高可用性」的設定互相比較，ClickHouse Managed Postgres 對上 RDS 的 Multi-AZ cluster 時，平均 TPS 約高 4 倍，p99 latency 約低 7 倍。差距主要出現在 RDS 的 2 個同步 standby 設定，其 p99 延遲來到 816.63 ms，是本次所有受測設定中最高的一筆。
影響範圍
PostgresBench 已開源，並提供互動式結果頁面（postgresbench.clickhouse.com），供任何人重新執行同一套測試方法驗證數字。對於正在挑選 Managed Postgres 供應商且需要 HA 的團隊，這份測試提供了一個可重現的基準，能拿自己的負載去對照不同複寫拓樸（非同步 vs 同步、shared-nothing vs shared-storage）在穩態下的效能落差。
原始來源：ClickHouse Blog
clickhousectl 讓 Agent 自己動手：橫跨三洲打造分散式 ClickStack
ClickHouse Blog · 2026-07-22
ClickHouse 發布一篇實作紀錄，展示如何用 clickhousectl 這支 CLI 讓 AI agent 自主佈署一套橫跨美國東部（us-east-1）、歐洲西部（eu-west-1）與日本（ap-northeast-1）三地的分散式 ClickStack。整個過程沒有透過 Web console 手動點擊，全部由 agent 呼叫 CLI 完成。
clickhousectl 的角色
clickhousectl 定位為「ClickHouse local 與 cloud 共用的 CLI」，讓 agent 能先在本機用 ClickHouse local 做原型驗證，再用同一支工具在 ClickHouse Cloud 佈署正式環境。它的指令輸出是結構化 JSON，agent 可以直接解析欄位，不需要額外寫爬蟲去解讀文字輸出。
三地架構
三個地區各自佈署一個獨立的 ClickHouse Cloud 服務，搭配區域內的 OpenTelemetry collector，負責就地收集當地應用程式產生的 log、trace 與 metric，資料不會跨境傳輸到其他區域再寫入。ClickStack 的 UI 則統一架在歐洲。查詢層是全域的：歐洲區域額外建了一個 otel_global 資料庫，靠 remoteSecure() 在查詢當下即時拉取另一個服務上的資料表，再用 Merge 引擎把三地的表接成單一邏輯表供查詢，藉此在維持各地資料落地（data residency）的前提下做跨洲查詢。
Agent 執行的操作
Agent 依序在三個區域迴圈執行服務建立、用 jq 解析回傳 JSON 取出 service ID 與 endpoint、再輪詢服務狀態直到變成 running，最後透過 clickhousectl cloud service query 執行建表 SQL。關鍵指令如下：
clickhousectl cloud auth login --api-key <KEY> --api-secret <SECRET>
clickhousectl cloud service create --org-id <ORG_ID> --region <REGION>
clickhousectl cloud service get <SERVICE_ID> --json權限模型上，瀏覽器登入僅取得讀取權限，建立與刪除服務則需要額外的 API key 授權，避免 agent 誤刪正式環境資源。
影響範圍
此案例展示的重點是把「跨區部署＋全域查詢」整個流程收斂成可被 agent 呼叫的 CLI 操作。告警機制同樣被納入自動化：文章提到兩種實作，一種是用腳本定期評估 SQL 規則，另一種是 ClickStack 原生告警、每分鐘評估一次。對於需要多區域資料落地限制、卻仍想要統一查詢入口的團隊，remoteSecure() 搭配 Merge 引擎是本文示範的具體做法。
原始來源：ClickHouse Blog
SQLite 3.53.4：修復一批由 AI 揪出的安全漏洞
SQLite Release Log · 2026-07-24
SQLite 發布 3.53.4，這是 3.53 系列的維護性修補版本，SQLITE_SOURCE_ID 為 2026-07-24 19:02:57。官方 release log 對這個版本的說明只有一句話：修補了 3.53.0（含 3.53.1、3.53.2、3.53.3）中發現的問題，且「多數是由 AI 找出來的」，細節導向原始碼的 check-in timeline。
修補內容
翻閱對應的 check-in 紀錄，這批修補以記憶體邊界檢查為主。其中兩筆明確標註來源：一筆是「三個由 AI 找出的、位於非必要延伸模組（non-deliverable extensions）中的獨立錯誤」，另一筆是 sqlite3_rsync 工具程式中「由 Anthropic 找出的三個缺陷」。主要修補項目如下：
- fts5 輔助 API 在處理 phrase number 時的越界讀取（OOB read）
- session 擴充模組在 changeset rebase 時的緩衝區越界讀取
- fts5 處理損毀（corrupt）記錄時的多筆緩衝區問題
- fossildelta.c 擴充模組中的單位元組越界讀取
- super-journal 處理強化，避免任意檔案刪除
- WAL 檔案中損毀頁面大小（page size）的處理
- 損毀 super-journal 記錄時的 hot journal 回滾修正
- RBU 擴充模組多筆緩衝區越界讀取與 delta 處理強化，抵禦刻意構造的惡意輸入
影響範圍
這些修補集中在 fts5、session、RBU 與 sqlite3_rsync 等擴充模組，觸發條件多半是讀入損毀或惡意構造的資料庫檔案、changeset 或 delta。一般只呼叫標準 SQL 介面、不使用上述擴充模組的應用不受影響，但有使用 FTS5 全文檢索、session/changeset 或 RBU 增量更新機制、且會處理不受信任輸入的部署，建議更新到 3.53.4。