CloudNativePG 1.30 發布：新增 DatabaseRole CRD 與 Primary Lease 機制，同步修補兩項權限提升漏洞
PostgreSQL News · 2026-07-06
CloudNativePG 專案於 2026 年 7 月 6 日發布 1.30.0 版，這是目前 Kubernetes 生態圈中管理 PostgreSQL 叢集最主要的 operator 之一。此版本除了新增兩項核心資源型別，也一併修補兩個已編號的權限提升漏洞，並將 cluster 參照欄位改為不可變更。以下整理本次發布的主要改動與其影響範圍。
核心改動
本次最大的功能新增是 DatabaseRole CRD，讓 PostgreSQL 的角色（role）可以用宣告式方式作為獨立的 Kubernetes 物件管理，每個角色擁有自己的生命週期與狀態，並可個別套用 RBAC 規則。這項設計對 GitOps 流程相當友善，角色定義可以直接放在使用它的應用程式旁邊一起版本控管。DatabaseRole 也支援透過 clientCertificate 區塊自動產生與更新 TLS 用戶端憑證，憑證會存放在 <databaserole-name>-client-cert 這個 Secret 中並自動清理，藉此可以啟用免密碼的 PostgreSQL cert 驗證方式。
另一項重要改動是 Primary Lease 機制：CloudNativePG 引入新的 Kubernetes Lease 物件，作為序列化 primary 晉升動作的互斥鎖。Instance manager 必須先取得該 lease 才能以 primary 身分運作，並在乾淨關機時主動釋放，讓 replica 可以立即晉升，不必等待 lease 的完整 TTL 到期。這個機制可透過新的 .spec.primaryLease 欄位設定，官方將其定位為晉升過程中的 gate（守門機制），而非硬性的 fencing 手段。
安全性方面，本版本修補了三個問題。CVE-2026-55769 修正一個 CWE-426（不受信任的搜尋路徑）權限提升漏洞：先前資料庫擁有者可以在 public schema 中植入覆寫版本的運算子，本版起 operator 會在連線池連線上固定 search_path = pg_catalog, public, pg_temp 以阻斷此攻擊面。CVE-2026-55765 則讓 operator 在下 CREATE／ALTER ROLE 指令前，先將明文密碼以 SCRAM-SHA-256 編碼，避免 SCRAM 驗證資料出現在日誌或 extension 擷取內容中。另外 GHSA-7qwx-x8ff-3px9 則讓 operator 與 instance manager 之間的通訊改用 ECDSA 憑證進行雙向驗證，這項變更僅存在於 1.30.0，不會回移（backport）至舊版，舊版使用者建議改用 NetworkPolicy 限制 instance 狀態連接埠的存取。
影響範圍
API 層面有一項破壞性變更：Database、Pooler、Publication、Subscription 與 ScheduledBackup 資源上的 cluster 參照欄位，現在變成不可變更（immutable），任何試圖改指到不同叢集的操作都會被 CEL 驗證規則拒絕。此外，使用 Image Volume extension 的叢集現在可以透過 side-by-side 掛載方式，使用 pg_upgrade 進行原地大版本升級。
其他值得留意的增強包括：Pooler 可透過 spec.pgbouncer.imageCatalogRef 參照 ImageCatalog 項目來管理 PgBouncer 映像檔版本；.spec.monitoring.tls.enabled 讓 Pooler 的 metrics 端點支援 TLS 並可熱重載憑證；透過新增的 status.selector，Cluster 現在可以作為 VPA／HPA 的 scale subresource 目標；當 primary pod 顯示 Ready 但 /pg/status 健康檢查失敗時，會發出 PrimaryStatusCheckFailed 警告事件；同時本版也加入對 Kubernetes 1.36 的支援，預設 PostgreSQL 版本更新為 18.4。
本次發布同時附帶兩個維護版本：1.29.2 回移了安全修補與部分增強功能；1.28.4 則是 1.28.x 系列的最後一個計畫版本。以下整理各分支目前的支援狀態：
| 版本分支 | 狀態 | EOL 日期 |
|---|---|---|
| 1.28.x | 已終止支援 | 2026-06-30 |
| 1.29.x | 維護中（最新為 1.29.2） | 2026-09-29 |
| 1.30.x | 目前主線版本 | — |
原始來源：CloudNativePG 1.30.0 Released!（PostgreSQL News）、CloudNativePG 1.30 Release Notes
印尼身分驗證新創 Verihubs 把資料倉儲從 Postgres 換成 ClickHouse，查詢加速最高 98%、雲端成本降低最高 50%
ClickHouse Blog · 2026-07-06
ClickHouse 官方部落格於 2026 年 7 月 6 日刊出一篇客戶案例，描述印尼身分驗證服務商 Verihubs 如何把原本建立在 Postgres 上的分析架構，遷移到以 ClickHouse 為核心的即時資料倉儲。Verihubs 提供人臉辨識、deepfake 偵測、活體檢測、eKYC 流程與 WhatsApp OTP 等服務，客戶包含多家銀行與金融科技公司，每月處理約 5000 萬次 API 呼叫。
原本的問題
Verihubs 原本的架構以 Postgres 作為 OLTP 資料庫，搭配 Airflow 執行每日批次資料拉取，再由一組 Docker service 連線處理資料，最後用 Metabase 呈現儀表板。隨著資料量成長，這套架構出現多重瓶頸：單一 service 的資料處理作業耗時長達 2 到 6 小時，查詢效能隨時間持續劣化。
更棘手的是資料新鮮度問題：因為依賴每日批次拉取，部分供應商的回呼（vendor callback）有時會延遲超過 20 天才抵達，而非原先預期的 24 小時內到位。晚到的資料一旦進系統，還需要重新處理，連帶導致帳單（invoice）必須重新產生、對帳作業也隨之延後。與此同時，backfill 操作又會拖累整個系統的查詢效能，使得團隊經常被問到資料為何不新鮮、查詢為何逾時。
採用的方法
遷移的核心目標有三個：讓分析從批次依賴改為互動式查詢、降低基礎設施成本，以及提供更即時、回應更快的資料給使用者。在資料攝取層，Verihubs 用 Kafka 即時串流取代原本的每日批次拉取，透過 Kafka Connect 持續攝取資料，並用 Debezium 做 CDC（change data capture）處理資料列的更新，同時借助 Kafka 內建的重試機制做錯誤復原。
在資料表設計上，團隊依資料特性選用不同的表引擎：只寫入、不更新的交易紀錄類資料採用 MergeTree 表，針對插入與分析型掃描做最佳化；需要透過 CDC 反映更新的資料集則採用 ReplacingMergeTree 表，可在不退回批次處理的前提下完成資料對帳（reconciliation）。後段處理則搭配 materialized view 把高流量資料預先聚合成日、月粒度的 rollup，並用 projection 在不更動底層 table schema 的情況下加速常見查詢；複雜的轉換邏輯與行為模式偵測（例如連續簡訊 spam 標記）交由 Dagster 編排，並串接 Slack 通知團隊可疑活動。整個轉換過程歷時約六個月完成。
實際效果
案例中提供了具體的查詢效能對比：以一組 1800 萬列的資料集為例，同樣的查詢原本在 Postgres 架構下需要 20 到 30 分鐘，遷移到 ClickHouse 後縮短到 2 到 3 秒。下表整理了官方公布的整體效益數字：
| 指標 | 遷移前（Postgres） | 遷移後（ClickHouse） |
|---|---|---|
| 查詢時間（1800 萬列資料集） | 20–30 分鐘 | 2–3 秒 |
| 查詢效能提升幅度 | 基準 | 最高 98% |
| 雲端基礎設施成本 | 基準 | 降低最高 50% |
團隊也整理了幾項遷移過程中的技術教訓：schema 設計必須謹慎正規化、減少下游 join、並仔細挑選 ordering key，否則後續可能需要昂貴地重建整張表；表引擎的選擇會直接決定 backfill、查詢與寫入策略的可行方式。另外，ClickHouse 的寫入行為與 Postgres 不同——mutation（更新、刪除）是漸進套用而非立即生效，這點需要提前與利害關係人溝通調整預期。
SQL 語法層面也存在差異：ClickHouse 的 JOIN 與 ORDER BY 行為與 Postgres 不完全一致，時間分桶（time bucketing）等常用轉換也仰賴 ClickHouse 原生函式，需要重寫既有查詢邏輯。最後，materialized view 與 projection 的差異也值得留意：projection 可以自動回溯既有資料，但 materialized view 不會自動從來源表 backfill，一旦有多層串接依賴，就需要額外規劃資料回填順序。