DuckDB Labs 上個月 ship 了 DuckLake 1.0,MotherDuck 接好了生產支援 — 一個 lakehouse 表格式,與 Iceberg 和 Delta Lake 在一個架構後果性的方面分歧:元資料不再是 object storage 上的 JSON 清單檔案,而是所有元資料和目錄都活在一個 SQL 資料庫裡。團隊對為什麼的 framing 直接 — file-based 元資料在 lake 格式裡導致複雜的協調、慢的元資料操作、和很多小檔案。MotherDuck 的發布數字聲稱在目錄熱路徑上 10x 更快的 queries 和 10x 更高的每秒事務。原始資料仍在 object storage 的 Parquet 裡;只有目錄搬到了 Postgres 級耐久性。授權 MIT。客戶端 ship 了 Apache DataFusion、Spark、Trino 和 Pandas — 第一天就是多引擎,不鎖 DuckDB。
對 builder 重要的機制是 data inlining。Iceberg 的小檔案問題是每個生產 lakehouse 都中招的慢性 compaction 債:stream 幾行,進一個新 Parquet 檔案,重複一萬次,現在你的 read 掃幾萬個小檔案直到 compaction job 追上。DuckLake 的 inlining 預設閾值是十行 — 低於這個直接跳進 SQL 目錄而不是生成新 Parquet 物件。1.0 裡有 sorted tables 和高基數列的 bucket partitioning、geometry 類型升級了、deletion vectors 明確與 Iceberg 相容 — DuckLake 發出的 vector 在現有 Iceberg consumer 上能乾淨地讀。互操作是刻意的;這是一個想在維運特徵而非 lock-in 上贏的格式。架構 tradeoff 是你現在在元資料路徑上有了 Postgres(或相容)可用性依賴。對大多數 builder 是 feature — Postgres 被為低延遲高並發讀 tune 了四十年。對沒有明顯中央目錄 DB 的 multi-region lakehouse builder,這是要繞著設計的新問題。
生態讀法:Iceberg 和 Delta Lake 之間的 lakehouse 格式戰爭到這地步已經十年了,維運上的答案沒出來。Iceberg 贏了元資料 spec 戰爭,但 Delta 還是 ship 更好的工具。DuckLake 從第三個軸進來 — 完全繞過 file-based 目錄。它不會取代那些已經有可用 compaction 管線和 Iceberg-native 查詢的生產 deploy 中的 Iceberg,但對 2026 年立起新分析層的 builder,SQL 目錄方法在維運上會看起來好得多。MotherDuck 的 pitch — 「setup 兩條 SQL 命令」 — 是誠實描述:如果你已經有 Postgres,你就有 DuckLake 目錄。多引擎支援意味著你不押注 DuckDB;你可以在 Trino 上跑重分析,同時輕量維運查詢直接打 DuckDB 同樣的資料。大的開放問題是從 Iceberg 遷移的路徑,發布公告留得很模糊 — 這是接下來 6 個月可能浮現的 workstream。
實際動作:如果你這個季度在搭一個新的分析層或 ML feature store,DuckLake 1.0 值得花一週對比 Iceberg eval。setup 簡化的差距本身就是真的 — 把你的 Glue/Hive Metastore 配置換成 Postgres connection string。如果你跑生產 Iceberg 還在調 compaction,遷移成本非零而且沒有文件路徑;當 DuckLake ship 雙向明確 Iceberg readers/writers 時再回來看。對頻繁寫小批次的 ML 管線(training-data 攝取、推理日誌、eval traces),data inlining 一項就解決了基於 compaction 的方法一直在交學費的一類維運痛苦。1.0 穩定 spec 承諾 + 向後相容承諾讓這對新 build 安全可押;對現有 build,問題是你當前的摩擦值不值得遷移成本。