DuckDB 在 8 月 17 日發表 v2.0 預覽，版本名「Cyanoptera」，取自栗胸鴨這種分布在美洲的紅棕色鴨子，預計今秋正式發布。自三月 v1.5 以來累積超過一萬次 commit，這次不只是加功能：新的 SQL 解析器、新的預設儲存格式、重寫的 C API，加上少數深思熟慮的破壞性變更。長期堅持單機內嵌的 DuckDB，正式把「伺服器模式」變成主角。
為什麼是大改版
團隊明講改版號不是儀式：v2.0 換掉 PostgreSQL 衍生的解析器、把預設儲存格式升到 2.0、重做 C API。三件事都動到檔案格式與二進位介面的地基，與其拖著舊包袱疊功能，不如一次講清楚。他在 DuckCon #7 的「State of the Duck」演說裡已預告過大半內容，這篇預覽文則把重點整理成十項。
DuckDB 當伺服器
最有感的變化來自 quack 擴充套件轉正：任何 DuckDB 行程都能把資料庫服務到網路上，另一端以原生協定（與 CONNECT 語法）連線。DuckDB 從第一天起就是 in-process 資料庫，使用者多年來一直敲碗 client/server 模式，現在真的來了。長駐服務、多人共用、集中管理，這些過去要在外面再包一層的用法，開始有原生答案。觸發器也是為長駐服務而生：支援 row 與 statement 級、可用 OLD/NEW 轉移表，對稽核與增量同步特別有用。
SQL 端的新東西
這一輪的語法糖都很實用。向量相似度搜尋有了 APPROX NEAREST join，top-k 直接寫成一個 join 子句；CTE 裡可以寫 INSERT、UPDATE、DELETE、COPY，把資料搬運變成管線步驟；schema 能巢狀；變數有了 $x 的新寫法；JSON 終於能原地修改，json_set、json_insert、json_replace、json_remove 都齊了；遞迴 CTE 加上 USING KEY 聚合，迭代演算法可以用純 SQL 表達。再加上 VARIANT 型別，半結構化資料不必先拆欄位就能進庫查詢。
引擎裡的三項大工程
非同步 I/O 是第一項。整個引擎導入非同步存取，Parquet 先行，CSV 與自家格式跟進，還有非同步 Parquet 寫入與 MMAP、DIRECT_IO 模式。I/O 層從此與查詢層各自擴展，物件儲存上的遠端查詢受惠最大。
第二項是新解析器。DuckDB 棄用 PostgreSQL 衍生的舊解析器，改用自研的 PEG-based 解析器：擴充套件可以掛進文法、錯誤訊息帶精確的原始碼位置，設計上與舊語法相容。團隊在 8 月 20 日另發一文詳解。
第三項是儲存格式 2.0。欄位 metadata 懶載入，寬表開得更快；DICT_FSST 字串壓縮預設開啟；刪除紀錄更省空間；讀取時的損毀驗證更嚴格。ICU 也整個移除，時區、曆法與排序改用內建實作，IANA 時區資料壓縮到約 45 kB，微基準還快了 2.2 到 2.6 倍。
性能方面，遞迴 CTE 引擎重寫後，百萬邊圖的單源可達性查詢從 4.90 秒降到 0.12 秒，約 40 倍；planner 也學會利用 DuckLake、Iceberg 與 Hive 分割，分區裁剪大幅擴張。
對資料團隊的意義
三個判斷。第一，DuckDB 正從「分析師筆電上的工具」長成可部署的服務，過去拿 PostgreSQL 硬撐的內部儀表板與 agent 後端，多了一個更輕的選項。第二，儲存格式與 C API 都是大改，升級前先在測試環境跑一遍，舊檔案與自行維護的擴充套件都會受影響。第三，與其記住十個功能，不如記住方向：DuckDB 想待在你系統的每一層——筆電、物件儲存、以及現在的伺服器。
參考來源
- A Preview of DuckDB v2.0 — DuckDB
- DuckDB v2.0: Your Database Deserves a Better Parser — DuckDB
- Discussion on Hacker News
本文由 AI 協助自上述來源整理，經人工審核後發布。