DuckLake v1.0：以 SQL 目錄取代物件儲存中的 JSON 元資料檔案
DuckDB/DuckLake · 2026-04-13
DuckLake 是一個 lakehouse 格式規格，自 2026-04-13 起隨 DuckDB v1.5.2 的 ducklake 擴充達到正式生產可用（v1.0）。
核心架構差異
Delta Lake 與 Apache Iceberg 將表格元資料以 JSON 或 Avro 檔案分散存放於物件儲存中，元資料更新本身就是一次物件寫入操作，受限於物件儲存的最終一致性。DuckLake 將所有元資料集中存放於一個 SQL 資料庫（catalog）——可以是 SQLite、PostgreSQL 或 DuckDB 本身——透過資料庫的 ACID 特性確保一致性。
小檔案問題的解法：Data Inlining
≤10 行（預設）的插入、更新、刪除操作直接儲存於目錄資料庫，不產生 Parquet 檔案，從根本上消除 lakehouse 小檔案問題，不需額外的壓縮工作。
進階型別支援
- VARIANT：二進位編碼的半結構化格式，壓縮比優於 JSON，支援分解（shredding）以改善查詢下推
- GEOMETRY：每個檔案存有邊界框統計，空間過濾器可進行檔案級剪枝
效能特性
COUNT(*) 可直接從目錄元資料回答（無需掃描 Parquet），報告加速 8 至 258 倍。基於 murmur3 的 bucket transform 與 Iceberg 相容。刪除向量採用 Puffin 檔案格式（Iceberg v3 相容）。
生態系統
ducklake 擴充位居 DuckDB 下載量前十，第三方實作已涵蓋 Apache DataFusion、Spark、Trino 與 Pandas。MotherDuck 提供託管的 DuckLake 服務，統一管理目錄與儲存基礎設施。v2.0 路線圖中列出 Git-like 分支、RBAC 與增量物化視圖。
原始來源：DuckLake、DuckDB 1.5.2
pg_clickhouse 更新：JSONB 子欄位下推、串流查詢結果與 SQL 時間函數
ClickHouse Blog · 2026-04-24
pg_clickhouse 是 PostgreSQL 的外部資料封裝器（FDW），允許直接在 PostgreSQL 查詢中存取 ClickHouse 表格。2026 年 4 月的更新（v0.1.10 與 v0.2.0）帶來三項主要改進。
JSONB 子欄位下推（v0.1.10）
JSONB 存取器現在可以在 SELECT 以外的子句（WHERE、ORDER BY、HAVING）中下推至 ClickHouse。實作將 JSON 屬性存取器轉換為 ClickHouse 的子欄位語法；-> 運算子回傳 JSONB 值時使用 toJSONString() 進行比較。jsonb_extract_path() 與 jsonb_extract_path_text() 支援多層路徑引數存取巢狀值。
HTTP 結果集串流（v0.1.10）
HTTP 驅動引入查詢結果串流，預設緩衝約 50MB 後開始回傳結果，並為後續批次重用記憶體。實測以 NYC 計程車資料集比較：v0.2.0 記憶體使用量上限 86 MiB，v0.1.10 峰值超過 600 MiB。
SQL 時間函數下推（v0.2.0）
日期/時間函數 CURRENT_DATE、CURRENT_TIMESTAMP、clock_timestamp()、statement_timestamp()、transaction_timestamp() 現在尊重 PostgreSQL session 時區設定，並下推至 ClickHouse 對應函數（toDate()、now64()、nowInBlock64()）。轉換時維持 PostgreSQL 的時間戳精度（預設 precision 6）。
陣列函數下推
新增 array_cat→arrayConcat、array_to_string→arrayStringConcat、string_to_array→splitByString 的下推對應。
原始來源：ClickHouse Blog
PostgreSQL 查詢計畫陷阱：參數化查詢如何讓部分索引失效
ohadravid.github.io · 2026-04-28
此文記錄了一個 PostgreSQL 與 SQLAlchemy 結合使用時，為稀有資料建立的部分索引（partial index）反而造成查詢效能劇降的案例。
場景
資料表 orders 有 440 萬行，item_type 欄位的分布嚴重偏斜（絕大多數為 KrabbyPatty 和 CoralBites，只有 2 筆 Special）。工程師建立了：
CREATE INDEX ix_timestamp_item_type_special ON orders (timestamp)
WHERE item_type = 'Special'預期此索引可使 Special 查詢從 1.6ms 降至毫秒以下，但實際測量結果為 238ms——反而更慢。
根本原因：準備語句的通用計畫
SQLAlchemy 的參數化查詢在 psycopg 中被轉換為 prepared statement。PostgreSQL 計畫器針對前五次執行使用自訂計畫（custom plan）計算平均估計成本，之後若通用計畫（generic plan）的估計成本低於自訂計畫的平均成本，就切換至通用計畫。通用計畫以 $2 占位符取代實際的 item_type 值，部分索引所依賴的值謂詞消失，計畫器無法確認此查詢滿足索引的 WHERE 條件。
診斷方法
透過 pg_prepared_statements 系統視圖觀察計畫從自訂切換至通用的時機；以 EXPLAIN 比較 $2 占位符與字面值版本的執行計畫，確認索引是否被使用。
解法
在交易內執行 SET LOCAL plan_cache_mode = force_custom_plan 強制每次重新計算計畫，查詢回到 1.01ms。
原始來源：ohadravid.github.io
ClickHouse Cloud 遷移至 Google Axion：ARM 架構帶來 30–55% 查詢加速
ClickHouse Blog · 2026-04-22
Google Axion 是 Google 的 ARM 架構處理器，驅動 C4A 執行個體系列。ClickHouse Cloud 完成遷移後，於 2026-03-11 的 ClickBench 綜合排名中取得第一。
架構優勢
與 x86 相比，Axion 提供更高的記憶體頻寬與更佳的每瓦效能。x86 以 1 個物理核心對應 2 個邏輯 vCPU（超執行緒），Axion 採 1:1 對應，在持續負載下頻率更穩定。
基準測試結果
ClickBench 使用 1 億行生產衍生資料集，涵蓋聚合、過濾、字串操作、複雜多欄掃描共 43 個查詢，全部查詢均勻提升 30–55%。資料載入時間約縮短 50%（24 GB 層級從 1,080 秒降至約 540 秒）。控制實驗（8 CPU、32 GB 記憶體）中，C4A-standard-8 在所有副本數量下均優於 n2d-standard-8，計算密集型分析工作負載提升 50–100%。生產機群整體每查詢運算積分降低約 15%。
原始來源：ClickHouse Blog
pgBackRest 停止維護：開源可持續性問題的具體案例
LWN.net · 2026-04-27
PostgreSQL 備份與還原工具 pgBackRest 已於 2026 年 4 月 27 日正式歸檔，結束 13 年的活躍維護。
原因
主要維護者 David Steele 最初受 Crunchy Data 資助進行開發。Crunchy Data 被收購後，Steele 失去企業支持，尋找替代贊助商與可持續開發職位的努力均未能達到繼續維護所需的門檻，最終宣布歸檔。
替代選項
社群討論提及兩個活躍替代方案：pgmoneta（在 Google Summer of Code 中持續活躍的備份專案）以及 pgBarman（由 2ndQuadrant/EDB 維護）。pgBarman 的創始人 Gabriele Bartolini 也就開源可持續性發表了評論。
更廣層面的問題
此案例展示了關鍵開源基礎設施對單一企業贊助的脆弱依賴：企業贊助帶來穩定的開發資源，但企業戰略變化直接威脅專案存續。社群討論聚焦於如何建立對單一贊助者更具韌性的多元資金模式。