數據庫火星撞地球：當 PG 愛上 DuckDB

昨晚在直播間，我與幾位國內 DuckDB 先鋒進行了一場對談。 話題跨度很大，從 DeepSeek 團隊在開源周推出的分佈式 DuckDB 分析框架 “Smallpond”，聊到 PostgreSQL 與 DuckDB 的深度融合，相當熱鬧。

DeepSeek 的開源的 “小池塘” 用把 DuckDB 改爲分佈式的用法，從營銷上給 DuckDB 打了很好的廣告。 但從實用角度和影響力來說，我個人對分佈式 DuckDB 的價值保持保留態度（那個 3FS 實際上更有用）。 因爲這與 DuckDB 本身的核心價值主張（大數據已死）完全背道而馳。

那麼如果不去折騰 “分佈式”，DuckDB 未來更有前景的方向是什麼？ 相比之下，我更加看好 “DuckDB + PostgreSQL 深度融合” 這路徑。 我甚至認爲，它可能會引爆數據庫世界下一場 “火星撞地球” 式的變革。

DuckDB：OLAP 挑戰者

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

現在你能看到的各種分析數據庫產品 ClickHouse，Snowflake，Databricks 背後都有它的影子。 而現在這些分析領域的先鋒們自己親自下場來做分析數據庫，他們選擇了一個非常好的時機與生態位切入，搞出了一個嵌入式的 OLAP 分析數據庫 —— DuckDB 。

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

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

同時，DuckDB 使用極爲友善的 MIT 許可證開源：一個有着頂尖性能表現，而使用門檻低到地板，還開源免費，允許隨意包裝套殼的數據庫，想不火都難。

取長補短的黃金組合

儘管 DuckDB 有着頂級的分析性能，但它也有自己的短處 —— 薄弱的數據管理能力， 也就是數據科學家們不喜歡的那些東西 —— 認證 / 權限，訪問控制，高併發，備份恢復，高可用，導入導出，等等等， 而這恰好是經典數據庫的長處，也是企業級分析系統的核心痛點。

從這個角度來說，duckdb 更像是 RocksDB 這樣的底層 “存儲引擎”，一個 OLAP 算子。 本身距離一個真正的 “數據庫” / “大數據分析平臺” 還有很多工作要做。

PostgreSQL 則在數據管理領域深耕多年，擁有完善的事務機制、權限控制、備份恢復和擴展機制。 傳統的 OLTP 場景下 PostgreSQL 更是 “老牌猛將” 。 但 PostgreSQL 的一個主要遺憾就是：儘管 PostgreSQL 本身提供了很強大的分析功能集，應付常規的分析任務綽綽有餘。 但在較大數據量下全量分析的性能，相比專用的實時數倉仍然有些不夠看。

那麼人們自然而然會想到，如果我們可以結合兩者的能力，PostgreSQL 提供全面的管理功能與生態支持，以及頂級的 OLTP 性能。 DuckDB 提供頂尖的分析算子和 OLAP 性能；二者深度融合，就能把各自優勢疊加，取長補短，在數據庫領域中產生一個 “新物種”。

DuckDB 能很好的解決 PostgreSQL 的分析短板，甚至還可以通過讀寫遠程對象存儲上的 Parquet 等列存文件格式，實現無限存儲的數據湖倉的效果；而 DuckDB 孱弱的管理能力也通過融合成熟的 PostgreSQL 生態得到完美解決。 比起給 DuckDB 套殼，搞一套什麼新的 “大數據平臺 / 數據管理系統”，或者給 PostgreSQL 發明一個新的分析引擎，兩者融合起來，取長補短，是一條阻力最小，而價值最大的道路。

實際上，這正是數據庫世界中正在發生的事情，許多團隊和廠商已經投入到 DuckDB + PostgreSQL 的縫合當中，試圖率先搶得這個潛力巨大的新市場。

羣雄逐鹿的縫合賽道

當我們把目光投向業界，不難發現 已經有諸多玩家入局了：

最早進入這條賽道的是國內個人開發者李紅豔開發的 duckdb_fdw，一直算是不溫不火的狀態。 然而在 《PostgreSQL 正在吞噬數據庫世界》以向量數據庫的例子預言了 OLAP 賽道的機會之後， PG 社區對征服 OLAP 縫合 DuckDB 的熱情被徹底點燃。

就在 2024 年 3 月的時間點上，一切驟然加速。ParadeDB 的 pg_analytics插件立即切換了技術路線，改爲縫合 DuckDB。

PG 生態發起 pg_quack 項目的 HYDRA 與 DuckDB 母公司 MotherDuck 開始合作，發起了 pg_duckdb。 官方開始下場， “不誤正業” 地不去折騰 DuckDB，反而搞起了 PostgreSQL 插件。

接下來，在數據庫熱點上一向嗅覺敏銳的 Neon 贊助了 pg_mooncake 項目，這個新玩家選擇站在 pg_duckdb 的肩膀上， 不僅要把 DuckDB 的計算能力給縫合入 PG，還要將 DuckDB / Parquet 開放分析存儲格式原生融合到 PG 的表訪問接口中，把存儲和計算能力一起縫合到 PG 中。而 Mooncake 打榜 ClickBench 進入前十，更是直接證明了的擴展這種模式的可行性與能力。

一些頭部雲廠商，比如 阿里雲 RDS  也在嘗試縫合包裝 DuckDB，標誌着已經有大玩家開始忍不住準備下場了。

這種場面很容易讓人聯想到早兩年的 “向量數據庫熱”。當 AI 檢索和語義搜索成爲熱點，不少廠商都 “聞風而動”，基於 PostgreSQL 開發向量數據庫插件， AI 爆火之後，PG 生態裏就湧現出了至少六款向量數據庫擴展（ pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale）， 並在你追我趕的賽馬中卷出了新高度。

最後 pgvector 在以 AWS 爲代表的廠商大力投入加註之下，在其他數據庫比如 Oracle / MySQL / MariaDB 的糊弄版本姍姍來遲之前， 就已經把整個專用向量數據庫細分領域給蕩平了，喫下了 RAG / 向量數據庫帶來巨大增量裏的最大蛋糕。而現在，似乎是這種賽事在 OLAP 領域的又一次預演。

爲什麼是 DuckDB+PG？

比較有趣的一點是，這樣的奇景同樣只出現在 PostgreSQL 生態中，而在其他數據庫社區中依然一片寂靜。 甚至 DuckDB 官方也在參加 PostgreSQL 縫合大賽，而不是其他什麼 DB 的縫合大賽。

所以有人會問：既然要跟 DuckDB 融合，爲什麼不選 MySQL、Oracle、SQL Server 甚至 MongoDB？ 難道這些數據庫就沒有管理能力，不需要取長補短，不能跟 DuckDB 融合，獲取頂級 OLAP 能力嗎？

PostgreSQL 與 DuckDB 是一對完美的組合，體現在三點上：功能互補，語法兼容，可擴展性：

首先，DuckDB 使用的是 PostgreSQL 語法，甚至語法解析器都是直接照搬 PG 的， 這意味着兩者關鍵接口的差異性非常小，天然具有親和力，也就是不怎麼需要折騰。

第二，PostgreSQL 和 DuckDB 這兩個數據庫均是公認的 “可擴展性怪物”。無論是 FDW、插件，還是新存儲引擎、新類型，都能以擴展的形式接入。 比起魔改 PG + DuckDB 的內核源碼，寫一個粘合兩邊現有接口的擴展插件顯然要簡單太多了。

這種天生的技術血緣親和力，讓 “PG + DuckDB” 的融合成本顯著低於所有其他組合，低到李老師這樣的獨立個人開發者都可以參賽（順勢而爲是好事，無任何貶義）。

與此同時 PostgreSQL 是世界上最流行的數據庫，也是主要數據庫中唯一有增長而且是高速增長的玩家，縫合 PostgreSQL 帶來的收益也要比其他數據庫大得多。

這意味着，“PG + DuckDB” 的融合，是一條 “阻力最小、價值最大” 的康莊大道，大自然厭惡真空，因此自然會有許多玩家下場來填補這裏的空白生態位。

統一 OLTP 與 OLAP 的夢想

在數據庫領域，OLTP 與 OLAP 的分裂由來已久。所有的 “數據倉庫 + 關係型數據庫” 架構、ETL 和 CDC 流程，都是在修修補補這道裂痕。 如果 PostgreSQL 在保留其 OLTP 優勢的同時，能嫁接上 DuckDB 的 OLAP 性能，企業還有必要再維護一套專門的分析數據庫嗎？

這不僅意味着 “降本增效”，更可能帶來工程層面的簡化：無需再爲數據遷移和多數據庫同步煩惱，也無需支付昂貴的雙套維護成本。 一旦有人把這件事做得足夠好，就會像 “一顆深水炸彈” 般衝擊現在大數據分析的市場格局。

PostgreSQL 被視爲 “數據庫界的 Linux 內核” —— 它的開源精神和極強的可擴展性允許無限可能。 而我們目睹着 PostgreSQL 使用這種方式，依次佔領了地理信息，時序數據，NoSQL 文檔，向量嵌入等領域。 而現在，它正準備向最後也是最大的生態位 —— OLAP 分析領域發起衝擊。

只要一個優秀的集成方案出現，能讓 DuckDB 提供的高性能分析與 PostgreSQL 的生態完美融合，整個大數據分析領域或許會因此大變天。 那些專門的 OLAP 產品，能否頂住這場 “核爆級” 衝擊？是否會像那些 “專用向量數據庫” 一樣凋零， 現在沒人願意給出答案，但我相信到時候大家都會有自己的判斷。

爲 PG 與 DuckDB 縫合鋪好路

PostgreSQL OLAP 生態的現狀，正如同兩年前的向量數據庫插件一樣，還處於早期階段。 但這已經足夠令人興奮：新技術的魅力就在於，你能預見它的潛力，就能率先擁抱它的爆發。

兩年前 PGVECTOR 爆火前夜，Pigsty 是第一波將其整合的 PostgreSQL 發行版，也是我將它提入 PGDG 官方擴展倉庫的。 而這場 DuckDB 縫合大賽，乾脆就是我點燃的。我自然也會在這場新的賽事中，提前爲 PG 與 DuckDB 的融合鋪好路。

作爲一名深耕數據庫領域的從業者，我正在把當前各家與 DuckDB 融合的 PostgreSQL 插件 全部打包成可直接安裝使用的 RPM 或 DEB 包，並在主流的十個 Linux 發行版上提供。這個是完全開源免費的，一些同行廠商已經使用 Pigsty 擴展倉庫作爲上游，向用戶交付這些強力的 DuckDB 縫合擴展。

這些擴展與 PGDG 官方內核完全兼容，開箱即用，讓普通用戶也能輕鬆體驗 “DuckDB + PG” 融合的威力。 最重要的是，提供一個縫合大賽的“競技舞臺”，讓所有玩家都平等參與進來。讓我們能夠更快的辨別出，誰會成爲 OLAP 分析中的那個 “pgvector”。

誠然，現在不少插件仍處於早期階段，穩定性和功能尚未達到 “企業級” 的標準。也有很多細節待完善。但機會總是屬於勇於擁抱新技術的人，而我相信，這場 “PG + DuckDB” 融合的大戲，毫無疑問將會是數據庫領域的下一個風口。

真正的爆炸即將開始

比起當下 AI 大模型落地在企業應用中仍顯 “虛浮” 的熱潮，OLAP 大數據分析 是一塊更爲龐大、也更現實的市場蛋糕。 而 PostgreSQL 與 DuckDB 的融合 則有望成爲衝擊這個市場的板塊運動，引發行業格局的深度變革，甚至徹底打破 “大數據系統 + 關係型數據庫” 兩套架構並行的局面。

或許再過幾個月到一兩年的時間，我們就能看到一個或多個 “融合怪物” 從這些實驗性項目中脫穎而出，成爲數據庫的新主角。 誰能先解決好擴展的易用性、集成度和性能優化，誰就能在這場新競爭中奪得先機。

對於數據庫行業而言，這將是一次 “火星撞地球” 般的深度震盪；對於廣大企業用戶而言，或許會迎來一場 “降本增效” 的巨大機遇。 讓我們拭目以待這場新趨勢如何加速成長，併爲數據分析與管理帶來新的可能。

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