誰整合好 DuckDB，誰贏得 OLAP 數據庫世界

在 《PostgreSQL 正在吞噬世界中》 一文中，我曾經拋出過這個問題：誰會最終統一數據庫世界？。我認爲是 PostgreSQL 生態與各種各樣的擴展插件 —— 而我的判斷是，要想征服 OLAP 這個最大也是最顯著的數據庫獨立王國，這個分析擴展一定與 DuckDB 有關。

PostgreSQL 一直以來都是我最喜歡的數據庫，然而我第二喜歡的數據庫在這兩年中從 Redis 變爲了 DuckDB。DuckDB 是一個非常小巧且強大的 嵌入式 OLAP 分析數據庫，在分析性能、易用性上都做到了極致水平，並且在所有數據庫中有着僅次於 PostgreSQL 的可擴展性。

正如兩年前開展的向量數據庫擴展插件賽馬一樣，當下 PG 生態進行的擴展競賽已經開始圍繞 DuckDB 進行 —— “誰更好地在 PG 中整合 DuckDB，誰就贏得 OLAP 世界的未來”。儘管已經有許多玩家在摩拳擦掌，但 DuckDB 官方親自下場，毫無疑問宣告着這場競爭已經進入白熱化。

DuckDB：OLAP 的新興挑戰者

DuckDB 是由 Mark Raasveldt 和 Hannes Mühleisen 兩位數據庫研究員在荷蘭阿姆斯特丹的國家數學與計算機科學研究所（Centrum Wiskunde & Informatica, CWI）開發的。CWI 不僅僅是一個研究機構，可以說是分析型數據庫領域發展背後的幕後推手與功臣，是列式存儲引擎與向量化查詢執行的先驅。

現在你能看到的各種分析數據庫產品 ClickHouse，Snowflake，Databricks 背後，都有 CWI 的影子。順便一提，Python 之父龜叔也是在 CWI 時創建 Python 語言的。然而，現在這些分析領域的先鋒們自己親自下場來做分析數據庫了，他們選擇了一個非常好的時機與生態位切入，搞出了 DuckDB 來。

DuckDB 的起源來自作者們對數據庫用戶痛點的觀察：數據科學家主要使用像 Python 與 Pandas 這樣的工具，不怎麼熟悉經典的數據庫。經常被如何連接，身份認證，數據導入導出這些工作搞的一頭霧水。那麼有沒有辦法做一個簡單易用的嵌入式分析數據庫給他們用呢？—— 就像 SQLite 一樣。

DuckDB 整個數據庫軟件源代碼就是一個頭文件一個 c++ 文件，編譯出來就是一個獨立二進制，數據庫本身也就一個簡單的文件。使用兼容 PostgreSQL 的解析器與語法，簡單到幾乎沒有任何上手門檻。儘管 DuckDB 看上去非常簡單，但它最了不起的一點在於 —— 簡約而不簡單，分析性能也是絕冠羣雄。例如，在 ClickHouse 自己的主場 ClickBench 上，有着能夠吊打東道主 ClickHouse 的表現。

另外非常值得稱道的一點是，因爲作者的薪水由征服稅收支付，他們認爲將自己的工作成果免費提供給任何人是他們對社會的責任。因此，DuckDB 是在非常寬鬆的 MIT 許可證下發布的。

我認爲 DuckDB 的崛起是必然的：一個有着頂尖性能表現，而使用門檻低到地板，還開源免費的數據庫，想不火都難。

在 StackOverflow 2023 年的開發者調研中，DuckDB 以 0.61% 的使用率第一次進入 “最流行的數據庫” 榜單中（第 29 名，倒數第四），結果僅僅一年過去，在 2024 年度開發者調研中，它就實現了 2.3 倍的流行度增長，前進到（1.4%）與 ClickHouse （1.7%）非常接近的流行度。

同時，DuckDB 也在用戶中攢下的極好的口碑，在開發者中受歡迎與喜愛的程度（69.2%）在主要數據庫中僅次於 PostgreSQL （74.5%）。如果我們觀察 DB-Engine 的熱度趨勢，更是不難看出它在 2022 年中開始一飛沖天的狂飆增長態勢 —— 雖然沒法跟 PostgreSQL 這種數據庫比，但目前甚至已經超過了所有 NewSQL 數據庫產品的熱度分了。

DuckDB 的短板與其中的機遇

DuckDB 是一個可以獨立使用的數據庫，但更是一個嵌入式的分析數據庫。嵌入式有好處也有壞處 —— DuckDB 儘管有着最強分析性能，但它最大的短板就在於薄弱的數據管理能力 —— 也就是數據科學家們不喜歡的那些東西 —— ACID，併發訪問，訪問控制，數據持久性，高可用，數據庫導入導出，等等等，而這恰好是經典數據庫的長處，也是企業級分析系統的核心痛點之一。

可以預期的是，市面上一定會很快出現一系列的 DuckDB 套殼產品來解決這裏的摩擦與 GAP。正好比當年 Facebook 開源了 KV 數據庫 RocksDB ，無數 “新的數據庫” 給 RocksDB 套了一層 SQL 解析器，就號稱自己是新一代數據庫去圈錢了 —— Yet another SQL Sidecar for RocksDB。向量檢索庫 hnswlib 開源後，無數 “專用向量數據庫” 給它套了薄薄一層皮，就去市場上圈錢了。然後搜索引擎 Lucene 和下一代替代 Tantivy 開源之後，又有無數 “全文檢索數據庫” 來給他們套殼賣。

實際上，這樣的事情已經在 PostgreSQL 生態中發生了。在其他數據庫產品和公司還沒來得及反應之前，PG 生態已經有五個玩家下場賽馬了，包括 ParadeDB 的 pg_lakehouse，國內個人開發者李紅豔編寫的 duckdb_fdw，CrunchyData 的 crunchy_bridge， Hydra 出品的 pg_quack；以及目前 MotherDuck 原廠也跑過來做 PG 擴展了 —— pg_duckdb。

第二屆 PG 擴展競速比賽

這不禁讓我想起了過去一年中，PG 生態裏向量數據庫擴展的例子。AI 爆火之後，PG 生態裏就湧現出了至少六款向量數據庫擴展（ pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale），並在你追我趕的賽馬中卷出了新高度。最後 pgvector 在以 AWS 爲代表的廠商大力投入加持之下，在其他數據庫比如 Oracle / MySQL / MariaDB 姍姍來遲的糊弄版本出來之前，就已經把整個專用向量數據庫細分領域給摧毀蕩平了。

那麼，誰會成爲 PG OLAP 生態的 PGVECTOR 呢？我個人的判斷還是原廠吊打同人，儘管 pg_duckdb 纔剛剛新鮮出爐，甚至連 v0.0.1 版本都還沒發佈。但從其架構設計上，已經不難判斷，它大概率會是最後的贏家。實際上這個生態賽道纔剛剛展開，就立即有收斂的趨勢了：

原本 Fork Citus 列存擴展的 Hydra （YC W22），在嘗試構建 pg_quack 感受到 DuckDB 震撼後，立刻拋棄原有的引擎和 MotherDuck 合作，搞出來了 pg_duckdb。融合了 PG 生態經驗的 Hydra 與 DuckDB 原廠弄的擴展，可以直接在數據庫內絲滑地讀取 PG 數據表，並使用 DuckDB 引擎進行計算，並且可以直接從文件系統 / S3 上讀取 Parquet / IceBerg 格式的文件，實現湖倉的效果。

同樣是 YC 投的初創數據庫公司 ParadeDB （YC S23），在嘗試了自己用 Rust 構建類似的分析產品 pg_analytics 並取得了不俗的成績之後，也選擇改換了路線，基於 DuckDB 打造 pg_lakehouse 擴展。當然，創始人 Phillipe 在 pg_duckdb 剛剛官宣之後也立刻宣佈投降，準備在 pg_duckdb 的基礎上進行進一步的開發而不是當競品。

國內個人開發者李紅豔開發的 DuckDB FDW 是另一條另闢蹊徑的道路。不是直接利用 PG 的存儲引擎接口，而是直接用外部數據源包裝器（FDW）的基礎設施，將 PG 和 DuckDB 對接到了一起。這引發了官方親自下場吐槽，將其作爲反例批判，也許是 MotherDuck 親自下場的一個動機：“我還在構思偉大藍圖，如何融合 PG 與 Duck 的力量，你小子動作也太快了，得給你一點官方震撼看看”。

至於 CrunchyData 搞的 cunchy_bridge ，或者其他數據庫公司搞的閉源套殼擴展，我個人感覺是很難有出息的。

當然，作爲 PostgreSQL 發行版 Pigsty 的作者，我的策略始終是 —— 你們賽你們的馬，反正所有這些擴展我都會打包並分發給用戶，讓用戶自己選擇與決策。就好比當初向量數據庫崛起的時候一樣，我就把 pgvector ，pg_embedding，pase，pg_sparse 等等這幾個最有前途的擴展打包分發出去。不管誰是最後的勝利者，反正 PG 和 Pigsty 都是摘桃子的贏家。

天下武功，唯快不破，在 Pigsty v3 中已經實裝了這三個最有前途的擴展插件： pg_duckdb，pg_lakehouse，以及 duckdb_fdw，當然還有 duckdb 二進制本體，開箱即用，讓用戶體驗一個 PostgreSQL 包打天下，OLTP / OLAP 雙冠全能王合體，真正 HTAP 的快樂。當然這個版本中，還會有整整 333 個 PG 生態的擴展插件，不過限於篇幅，那就是下一篇的故事了。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TJk9TUW7xsEglhEK_qYi-w