2026-05-17 — DuckDB Quack 協議、PostgreSQL 多版本安全更新、ClickHouse vs Prometheus 高基數

Quack：DuckDB 自訂的 Client-Server 協議

DuckDB Blog · 2026-05-12

DuckDB 團隊於 2026 年 5 月正式發布 Quack 協議，讓 DuckDB 具備原生的 client-server 通訊能力。DuckDB 原本的定位是 in-process 分析資料庫；Quack 填補了多個並發客戶端讀寫同一資料庫的缺口，同時刻意選擇 HTTP 作為底層傳輸而非自定義二進制協議。

協議設計

Quack 以 HTTP 為基礎，請求與回應的 MIME 類型為 application/duckdb，序列化格式使用 DuckDB 內部的高效序列化原語——這些原語在 Write-Ahead Log 已使用多年，有充分的測試驗證。一次查詢可在單一 round-trip 內完成，優於 Arrow Flight SQL 需要兩次 round-trip 的設計，降低延遲敏感場景的開銷。

安全模型方面，伺服器啟動時生成隨機認證 token，客戶端必須提供匹配的 token。預設僅綁定 localhost，不啟用 SSL；公開網路部署建議透過 nginx 等反向代理處理 TLS。預設連接埠為 9494。

效能數據

情境	Quack	Arrow Flight	PostgreSQL
大量傳輸（6000 萬列）	4.94 秒	17.40 秒	158.37 秒
小量寫入（8 執行緒並發）	5,434 tx/s	~1,358 tx/s	4,320 tx/s

設計取捨

DuckDB 團隊明確拒絕採用 Arrow Flight SQL，理由有三：保留自訂序列化的創新空間、避免外部格式限制、以及實現單次 round-trip 查詢執行。選擇 HTTP 而非私有 TCP 協議讓既有的負載均衡、認證中介層與防火牆規則得以直接複用，降低基礎設施整合成本。

原始來源：DuckDB Blog — Quack: The DuckDB Client-Server Protocol

PostgreSQL 18.4～14.23 安全更新：11 個 CVE，4 個 CVSS 8.8

PostgreSQL Project · 2026-05-14

PostgreSQL 全球開發小組於 2026 年 5 月 14 日發布版本 18.4、17.10、16.14、15.18 與 14.23，修補 11 個安全漏洞與超過 60 個已知缺陷。此次更新涵蓋所有目前支援的版本分支，無需 dump/reload 或 pg_upgrade，僅需停止服務並替換二進制檔案。

高嚴重性漏洞

CVE-2026-6473（CVSS 8.8）：整數溢位導致記憶體分配過小，引發 segfault，影響版本 14–18
CVE-2026-6475（CVSS 8.8）：pg_basebackup/pg_rewind 符號連結追蹤，允許 origin 超級使用者覆寫任意本地檔案
CVE-2026-6477（CVSS 8.8）：libpq 的 lo_export()、lo_read()、lo_lseek64()、lo_tell64() 堆疊緩衝區溢位，影響 psql 與 pg_dump
CVE-2026-6637（CVSS 8.8）：refint 模組的堆疊緩衝區溢位與 SQL 注入，可透過使用者控制的 refint cascade 主鍵更新達成，允許以資料庫 OS 使用者身分執行任意代碼

其他漏洞

CVE-2026-6476（CVSS 7.2）：pg_createsubscriber SQL 注入，影響版本 17–18
CVE-2026-6479（CVSS 7.5）：SSL/GSS 初始化 DoS
CVE-2026-6472（CVSS 5.4）：CREATE TYPE 缺少多範圍 schema 權限檢查，允許透過 search_path 執行任意 SQL 函式
CVE-2026-6474、CVE-2026-6478、CVE-2026-6575、CVE-2026-6638：低至中度嚴重性（CVSS 3.7–6.5）

影響範圍

PostgreSQL 14 將於 2026 年 11 月 12 日到達 EOL，屆時不再收到安全更新。使用 libpq 的客戶端工具（psql、pg_dump）因 CVE-2026-6477 也需要同步升級，不僅是伺服器端。CVE-2026-6475 的利用條件包括符號連結在伺服器重啟前被移動或虛擬機快照，實際利用難度偏高，但仍建議優先修補。

原始來源：PostgreSQL 官方公告

ClickHouse vs Prometheus 高基數指標，第一篇：問題的本質

ClickHouse Blog · 2026-05-14

ClickHouse 官方部落格開始發布系列文章，比較 ClickHouse 與 Prometheus 在高基數（high-cardinality）指標場景下的架構差異。第一篇聚焦於問題定義：什麼是高基數，它為何讓 Prometheus 的設計假設失效，以及 ClickHouse 的不同設計取向。

高基數的問題本質

Prometheus 的 time-series 資料模型以 label set 作為唯一 key，每個 label 組合對應一條獨立序列。當 label 的值域龐大（如 user_id、request_id、trace_id），序列數量呈指數級增長，帶來記憶體壓力、查詢延遲上升、以及 TSDB 的 chunk 分裂問題。

Prometheus 的記憶體使用量與活躍序列數量正相關，每條序列在記憶體中維護獨立的 chunk。當基數超過數百萬時，TSDB 的設計邊界被突破，scrape 延遲與 OOM 成為常見症狀。

ClickHouse 的不同取向

ClickHouse 以列式儲存與向量化執行為基礎，不對 label 組合建立索引，而是依賴壓縮後的列資料與稀疏索引支援大範圍掃描。這使它在超高基數的 ad-hoc 查詢場景下不受 TSDB 序列數量上限的約束，代價是不適合毫秒級的實時 alerting 路徑（Prometheus 的強項）。

原始來源：ClickHouse Blog

End of article