最近，圖靈獎得主、Postgres 創(chuàng)始人、MIT 與 UC Berkeley 計算機系教授 Mike Stonebraker， 以及數(shù)據庫領域大網紅、卡耐基梅隆大學數(shù)據庫系教授 Andy Pavlo 聯(lián)合主持了一期播客， 回顧了 2025 年 AI 對數(shù)據庫的影響、數(shù)據庫行業(yè)的重大事件，以及 AI 對計算機科學教育和職業(yè)發(fā)展的作用。

老馮轉錄了視頻的文字稿，翻譯并點評了一下，供大家參考。

Data 2025：年度回顧 —— Mike Stonebraker 與 Andy Pavlo 對談錄 錄制于 2025 年 12 月 10 日 對談嘉賓：Mike Stonebraker（MIT CSAIL，圖靈獎得主，PostgreSQL 創(chuàng)始人）、Andy Pavlo（卡內基梅隆大學），主持：DBOS 團隊 原文地址：Data 2025: The year in review with Mike Stonebraker 中文譯評：馮若航

[0:00] 主持人（DBOS）： 大家好，感謝各位參加今天的活動。我們將與 Mike Stonebraker 和 Andy Pavlo 一起回顧 2025 年的技術發(fā)展。

今天的議程包括：深入探討 AI 與數(shù)據管理之間的相互影響——AI 趨勢如何改變數(shù)據管理，數(shù)據管理趨勢又如何反過來影響 AI。我們也會談到 AI 在數(shù)據庫運維自動化方面的應用。

之后，Andy Pavlo 將回顧今年行業(yè)發(fā)生的重大事件——里程碑式的進展、收購案、新公司的誕生、已經退出歷史舞臺的公司、被收購的公司，并探討這些變化將如何塑造 2026 年乃至更長遠的數(shù)據管理和軟件開發(fā)格局。

最后，我們會展開一場非常有意思的討論：AI 正如何影響計算機科學——它改變了教學方式、研究方式，以及許多人的職業(yè)發(fā)展道路。最后大約留 10 分鐘進行問答。

熟悉 DBOS 的朋友可能知道，它曾經代表 Database Operating System（數(shù)據庫操作系統(tǒng)）。這家公司起源于 MIT 和斯坦福的一個研究項目，最初是因為聯(lián)合創(chuàng)始人 Matei Zaharia 請 Mike 幫忙解決 Databricks 的持久化分布式隊列問題。這個契機催生了一個研究項目：在分布式數(shù)據庫之上構建操作系統(tǒng)，作為 Linux 的潛在替代方案——一個從設計上就更加云原生的系統(tǒng)。

如今，DBOS 代表 Durable Backends that are Observable and Scalable（持久、可觀測、可擴展的后端）——這個縮寫是我后來硬湊的。如果你了解 DBOS，它是一個開源的持久化工作流編排庫，能讓你的應用程序和后端具備故障恢復能力，同時提供可觀測性，并通過更簡便的隊列機制實現(xiàn)彈性擴展。正如一位 DBOS 用戶精辟總結的：DBOS 讓你想搞砸都難。這也是為什么 DBOS 在眾多新興 AI 應用公司中如此受歡迎——他們需要 AI 工作流無論遇到什么意外情況都能按預期運行。

Michael 稍后會詳細講解持久性與 Agentic AI 之間的關系。簡單說，這就是 DBOS。如果你正在構建軟件，想讓它輕松實現(xiàn)防錯和可觀測，可以了解一下 DBOS 開源庫。

你可能會好奇：我們不是數(shù)據庫公司，為什么要舉辦數(shù)據庫研發(fā)的網絡研討會？原因是：Postgres 的發(fā)明者 Mike Stonebraker 是 DBOS 的聯(lián)合創(chuàng)始人；我們也和 CMU 的 Andy Pavlo 是好朋友——他發(fā)明了"數(shù)據庫學"（databaseology）這個詞，同時也是 "So You Don't Have To" AI 的創(chuàng)始人，這是一個 AI 驅動的數(shù)據庫調優(yōu)服務，推薦大家去看看。好，閑話少說，讓我們開始今天的議程，聽聽 Andy 和 Mike 怎么說。

第一部分：AI 如何影響數(shù)據管理？

[4:03] 主持人： 第一個話題是：AI 如何影響數(shù)據管理？數(shù)據管理又如何影響 AI？Mike，你先來？

[4:10] Mike Stonebraker： 謝謝 Andy。還有另一位 Andy，你好。我得先說一下，我現(xiàn)在身體不太舒服，狀態(tài)不是 100%，所以 Andy P，你得對我手下留情。

Sam Madden 幾周前把生成式 AI 和大語言模型形容為"自切片面包以來最偉大的發(fā)明"——他沒有原話這么說，但意思差不多。我的看法要保守得多，讓我分享一下我使用大語言模型的經驗。

【譯注】"自切片面包以來最偉大的發(fā)明"（the best thing since sliced bread）是英語中一個常見的俚語，用來形容某樣東西非常了不起、革命性。這個說法源于 1928 年美國發(fā)明的預切片面包，當時被認為是家庭生活的重大便利創(chuàng)新。

我關注的是企業(yè)數(shù)據，所以一個顯而易見的問題是：能不能用大語言模型來查詢數(shù)據倉庫？業(yè)界有一些公開的基準測試——BIRD、Spider、Spider 2——報告的準確率在 60% 到 90% 之間，看起來相當不錯。但這不是我在真實數(shù)據倉庫上的體驗。

我們試了 MIT 數(shù)據倉庫的一個子集，里面有學生、課程、教職員工、專業(yè)等各種信息。我們找了真實用戶——事實上，我所在的 MIT CSAIL 實驗室就是這個數(shù)據倉庫的真實用戶。我們收集了真實用戶的查詢，搞清楚對應的標準 SQL 是什么，于是我們有了一批"自然語言-標準 SQL"的配對數(shù)據。

我們用各種 LLM 在 MIT 數(shù)據倉庫上測試，準確率是零。不是說很低——是零。什么都查不出來。

然后我們嘗試了所有標準技術——RAG、把查詢分解成更簡單的部分、從其他來源補充數(shù)據——準確率勉強提升到 20% 左右。如果我們告訴 LLM 具體要查哪張表或哪幾張表，能提升到 30% 左右。但離實際可用還差得遠。

你可能會說，也許 MIT 的數(shù)據是特例。但我們在七個不同的真實數(shù)據倉庫上測試，結果每次都一樣。

有些人報告了更好的結果，但我持懷疑態(tài)度。原因如下——MIT 數(shù)據倉庫有什么特點讓它如此困難？

第一，這不是公開數(shù)據。 LLM 根本無法訪問這些數(shù)據，因為它們受到各種隱私和安全保護。

第二，MIT 有很多獨特的術語。 如果你想查"過去兩年誰主修了計算機科學"——MIT 數(shù)據倉庫回答不了這個問題，因為 MIT 根本不用"計算機科學"這種說法。計算機科學實際上叫 "Course 6.2"。還有 J-term，是一月份的一個月學期。這些東西你不能指望 LLM 知道。

第三個問題是我所說的"語義重疊"。 MIT 的數(shù)據倉庫里充滿了物化視圖，這些視圖是為了加速常用查詢而存在的。但問題在于，它給你提供了多種方式來回答同一個查詢，而且語義往往略有不同——比如有些數(shù)據是按月的，有些是按周的。

第四是復雜查詢。 這些查詢大多涉及三到四張表的連接，還帶有聚合操作，相當復雜。

[10:00] 因此，如果你的數(shù)據庫具有這四個特征中的任何一個——非公開、術語獨特、語義重疊、查詢復雜——我對用 LLM 解決問題不抱樂觀態(tài)度。

所以我的思路其實不太一樣。要想把 Text-to-SQL 做好——首先，在企業(yè)環(huán)境中，真正的問題是這樣的：我有 ERP 系統(tǒng)、CRM 系統(tǒng)，還有一大堆其他系統(tǒng)和大量文本，我想查詢類似"誰既是我的供應商又是我的客戶"這樣的問題。這需要查詢多個私有數(shù)據源，既有文本也有 SQL。這本質上是數(shù)據湖問題。

怎么解決數(shù)據湖問題？讓我舉個簡單的例子。我們有個學生在和德國慕尼黑市合作，處理他們的交通部門數(shù)據。有各種各樣的查詢，比如：為什么這個路口的綠燈時間不長一點？或者，電車通過沒有紅綠燈的路口時最高時速是多少？慕尼黑市有六七個不同的數(shù)據源，理論上可以回答這些問題。這是典型的數(shù)據湖場景。

我的觀點是：最簡單的方法是把這些數(shù)據源包裝成一個非常小的 SQL 子集，讓用戶能夠表達他們想要什么。我主張系統(tǒng)的頂層應該是面向 SQL 的，而不是面向 LLM 的。 這是我正在研究的方向。也許這是個特例，也許不是。也許 Amazon 最近發(fā)布的 Bedrock 能在這方面有所幫助。

我留給大家一個測試：試著問你最喜歡的 LLM 這個問題——"有多少 MIT 教授有維基百科頁面？"這個查詢有兩個問題。第一，"誰是 MIT 教授"的答案在 MIT 數(shù)據倉庫里——我剛才說的那些問題都適用。第二個問題是維基百科，這是另一個數(shù)據源，它有個很好用的界面——你輸入某人的名字就能看到他們的頁面。LLM 最近開始能做這個了。但我很容易給你出一個更復雜的問題，它們就答不上來了。

我的思路是：給 MIT 數(shù)據倉庫包一層封裝，讓它足夠簡單，能夠通過 Text-to-SQL（或者 Text-to-簡化SQL）來回答問題；然后給維基百科包一層封裝，就是一個"查找 Andy Pavlo"或"查找任何人"的接口。然后把這兩個系統(tǒng)做一個連接操作。要用迭代替換，因為維基百科頁面比 MIT 教授多得多。

在我看來，這變成了一個查詢優(yōu)化問題——查詢優(yōu)化器最擅長解決這類問題。這就是我的研究方向。

當然，這些觀點要打很大的折扣。第一，我只關注企業(yè)數(shù)據，別人可能關注很多其他領域。第二，我主要關注的是防火墻內部、LLM 無法訪問的數(shù)據。所以我的經驗可能比較特殊。在我看來，LLM 在某些事情上表現(xiàn)很好，但可能不是所有問題的答案。

好，現(xiàn)在讓 Andy Pavlo 來說說，他對世界的看法要樂觀得多。

第二部分：Andy Pavlo 談 LLM 與 Vibe Coding

[15:21] Andy Pavlo： 說到維基百科，我還想提一嘴——我的維基百科頁面被刪掉了，因為我的簡介里寫我是"在巴爾的摩街頭出生的"（born in the streets of Baltimore），實際上我是在巴爾的摩出生的，但顯然不是在街頭。

【譯注】這里 Andy 在自嘲。"Born in the streets" 聽起來像是說在街頭流浪時出生的，有一種"街頭混混"的既視感，而實際上他只是在巴爾的摩市出生而已。維基百科可能因為來源不可靠或措辭不當而刪除了他的頁面。

總之，我對 LLM 取得的成就要樂觀得多。在自然語言轉 SQL 這件事上，對于某些特定挑戰(zhàn)，確實會有困難。但我更關注的是全新應用（greenfield applications）——未來的企業(yè)應用總要從某個地方開始，而它們現(xiàn)在就在開始。

【譯注】Greenfield（綠地）在軟件開發(fā)中指從零開始構建的新項目，沒有歷史包袱，與 brownfield（棕地，指在既有系統(tǒng)上改造）相對。

Andrej Karpathy 去年創(chuàng)造了 "vibe coding"（氛圍編程/憑感覺寫代碼） 這個詞，我們看到大量新應用幾乎完全由 LLM 或編程代理生成。你可能會問："這些代碼比人寫的好還是差？"差不多，因為這些模型是在海量代碼語料上訓練的。人類有時寫好代碼，有時寫爛代碼——LLM 也一樣。

【譯注】Vibe coding 是 Andrej Karpathy（前 OpenAI/Tesla AI 總監(jiān)）提出的概念，指的是用自然語言描述你想要什么，讓 AI 幫你生成代碼，你只需要"感覺"一下對不對，而不是逐行編寫。這個詞帶有一點調侃意味，暗示程序員只需要"找感覺"，不用真正懂代碼。

我對 LLM 作為編程代理的能力相當看好。說說我們自己的經驗：我們在卡內基梅隆教的課程，項目都是用 C++ 寫的。一年前，LLM 能解決一部分項目，但不是全部——它能生成代碼，但不是所有代碼都正確或有用。現(xiàn)在已經到了這樣的程度：我們的項目幾乎可以完全由 LLM 編寫和解決。

所以我認為 vibe coding 是真實存在的趨勢，我們將看到更多基于數(shù)據庫的應用涌現(xiàn)。但挑戰(zhàn)在于：你有這么多代理在生成新的應用代碼，這些代碼會和數(shù)據庫交互、讀寫數(shù)據?，F(xiàn)在我們要處理所有涌向數(shù)據庫系統(tǒng)的負載。

在 LLM 出現(xiàn)之前，所有應用代碼都是人寫的，它們會訪問數(shù)據庫系統(tǒng)，你很幸運才能有一個人類或 DBA 來維護、優(yōu)化和監(jiān)控這些數(shù)據庫系統(tǒng)。現(xiàn)在人類不寫代碼了，也沒有人類監(jiān)控數(shù)據庫系統(tǒng)了——這簡直是災難的完美配方。

[18:01] 在研究方面，我們已經研究了好幾年如何用機器學習和 AI 技術來自動化數(shù)據庫系統(tǒng)的管理和優(yōu)化。這不是 AI 突然帶來的新能力——人們從 1970 年代就開始嘗試了。最早的工作之一是自動為關系數(shù)據庫選擇索引——1976 年 SIGMOD 上就有相關論文。Microsoft 的 AutoAdmin 項目也在做這件事。

但我們研究的是從整體上看待數(shù)據庫系統(tǒng)——嘗試調優(yōu)數(shù)據庫系統(tǒng)中所有可調的東西，以應對來自 vibe-coded 應用的隨機查詢，同時關注數(shù)據庫系統(tǒng)的整個生命周期。

事實證明，LLM 在這方面相當擅長。我們現(xiàn)在研究的是如何同時調優(yōu)數(shù)據庫系統(tǒng)暴露給你的所有配置。已有很多工作研究如何調優(yōu)單個方面——"你需要什么最佳索引"或"系統(tǒng)需要什么最佳配置參數(shù)"——比如 Postgres 的 shared_buffers 或 MySQL 的 innodb_buffer_pool_size。但所有這些工具都只針對一件事。我們研究的是：如何同時調優(yōu)所有東西？因為這樣才能找到數(shù)據庫的真正全局最優(yōu)配置。

在我們這個領域的最新工作中，我們不是用 LLM 來做決策，而是用 LLM 來實現(xiàn)不同類型數(shù)據庫或不同數(shù)據庫部署之間的知識遷移。我們的算法可以在一個流程中調優(yōu)索引、配置參數(shù)、查詢計劃提示、表級參數(shù)、索引日志——基本上是 Postgres 暴露給你的所有東西。我們可以把這些全部一起調優(yōu)。

但問題是，你得為這個特定的數(shù)據庫實例訓練非常專用的模型。我們最新的工作是利用 LLM 來識別彼此相似但不完全相同的數(shù)據庫。然后我們可以把從調優(yōu)一個數(shù)據庫收集的所有訓練數(shù)據，應用到另一個數(shù)據庫上——效果出奇地好。

[20:40] 關于這些算法的性能，我要說的是：當前研究表明，這種專門為數(shù)據庫優(yōu)化和調優(yōu)定制的算法，比 LLM 能做到的好兩到三倍。但 LLM 速度很快——ChatGPT 能在 15 分鐘內給你的數(shù)據庫吐出一套方案，而我們最好的算法現(xiàn)在需要 50 分鐘。所以這是速度和質量之間的權衡。根據問題的嚴重程度和你的需求，你可能會選擇其中一個。

[21:21] 現(xiàn)在我們在研究的另一個很酷的東西——也是我非?？春?LLM 的原因——是推理代理（reasoning agents）：識別問題，然后決定調用哪個子代理或工具來解決它。比如，如果有異常檢測，數(shù)據庫系統(tǒng)有某種延遲問題，推理代理可以決定："我要運行這個工具來構建索引，因為我認為這就是當前的問題；我要運行另一個工具來優(yōu)化存儲性能。"

這就是我認為在未來一年左右會出現(xiàn)的真正酷炫的東西：能夠同時審視一堆不同的問題，并決定調用哪個子代理。子代理可以是 LLM，也可以是這些定制算法之一。我認為這非常令人興奮，LLM 在這個領域絕對是顛覆性的。

第三部分：Agentic AI 與數(shù)據庫技術

[22:18] Mike Stonebraker： 我認為，至少在數(shù)據管理領域，自動調優(yōu)應該能成功，因為它理應可行，理應具有商業(yè)價值。所以我很高興看到"OtterTune 二代"還活著，盡管 OtterTune 本身沒能成功。

【譯注】OtterTune 是 Andy Pavlo 之前創(chuàng)辦的數(shù)據庫自動調優(yōu)公司，后來關閉了。Mike 這里用"Son of OtterTune"（OtterTune 之子）來調侃 Andy 新的創(chuàng)業(yè)項目 "So You Don't Have To" AI。

[22:52] Andy Pavlo： 我得說，OtterTune 面臨的挑戰(zhàn)是——因為我們不托管數(shù)據庫系統(tǒng)——存在形態(tài)問題，需要用戶授權我們連接到他們的數(shù)據庫。而且 OtterTune 是被動調優(yōu)，在系統(tǒng)外部觀察發(fā)生了什么，然后做改變，再觀察后來發(fā)生了什么。

我們現(xiàn)在做的新工作不同——我們不是要托管數(shù)據庫系統(tǒng)，而是尋求與現(xiàn)有平臺集成。如果你在應用程序和數(shù)據庫服務器之間放一個代理（想想 PgBouncer、PgCat、PgDog——現(xiàn)在有很多這樣的 Postgres 代理和其他系統(tǒng)的代理），你就能看到查詢到達時的樣子，可以在查詢進入時操縱它們。我們仍然不托管數(shù)據庫系統(tǒng)本身，但至少現(xiàn)在我們能看到我們所做改變的效果——這對我們能做的事情產生了很大影響，而 OtterTune 做不到這一點。

從商業(yè)角度，我們現(xiàn)在的做法是：不再做一個獨立產品讓用戶注冊、連接數(shù)據庫、授權等等，而是在討論與現(xiàn)有平臺做 OEM 白標集成。這讓我們可以專注于 ML 數(shù)據庫這一塊，而不用操心開發(fā)者體驗和入職流程。

[24:20] Mike Stonebraker： 好吧，祝你好運，希望你成功。

Andy Pavlo： 謝謝 Mike。

[24:26] Mike Stonebraker： 我想談一件事：整個世界都愛上了 Agentic AI。在我看來，Agentic AI 意味著你有一個工作流，里面有些是 LLM，有些是 AI，有些是別的什么。也就是說：如果 LLM 不能直接做某件事，也許你可以在它周圍加一些東西，讓它更成功。我們在 MIT 做了很多這方面的工作。

DBOS 早期發(fā)現(xiàn)的一件事是：總體而言，Agentic AI 應用需要持久化計算（durable computing），因為這些東西很多是長時間運行的，如果出錯，你不想從頭再來。所以持久化計算在 Agentic AI 中是個大問題。有一堆商業(yè)產品在做這個。

但到目前為止，Agentic AI 基本上是我所說的"只讀"——你查詢一堆地方，然后拼湊出結論，比如"我預測 Andy Pavlo 的 OtterTune 繼任者會成功"之類的。

我認為用不了多久，Agentic AI 就會變成"讀寫"的。這意味著持久化計算本質上就是事務系統(tǒng)中 ACID 的 D（Durability，持久性）。完全是同一回事?，F(xiàn)在大家實現(xiàn)持久性的方式都在使用數(shù)據庫技術——你有一個日志，如果出了問題，你回滾然后重放。

[26:39] 所以這將是一個數(shù)據庫問題，而妙處在于：它要求你把應用狀態(tài)放進數(shù)據庫。正如 Andy Pavlo 剛才說的，我相信數(shù)據庫將逐漸接管應用程序狀態(tài)的存儲——因為這樣你就能獲得持久性。

但一旦涉及讀寫……我最喜歡的例子是：假設你在經營一家在線自行車店。服務器端的大致流程是這樣的：客戶進來說"我想買一輛 XYZ 自行車"。你的第一個動作是："我有沒有這輛車？"所以你需要查詢庫存，如果有就預留它。

第二步，如果有貨，你要確認是否愿意和這個客戶做生意。這可以用 LLM 來判斷：這個客戶是不是退貨太多？信用評級如何？等等。

如果都沒問題，第三步就是收錢——PayPal 或者你喜歡的任何支付系統(tǒng)。如果這也沒問題，就發(fā)貨。

所以基本上是四個步驟，每個都是一個事務，大多數(shù)涉及更新操作。比如，如果你給履約系統(tǒng)一個錯誤的地址，它就得把所有東西回滾。這些步驟里有一堆更新操作。

[28:36] 這就是涉及更新的場景。你必須處理失敗情況。持久性只處理正向場景——完成你的工作流。你還必須處理回滾，這需要某種原子性的概念。

[29:04] 我認為搞清楚 ACID 對工作流來說到底意味著什么，是一件大事。我正在推銷我為 CIDR 寫的一篇論文，將在一月份發(fā)表。我認為那是一個過渡性的解決方案，但不是最終方案。搞清楚這一切還需要一些時間。

另一個問題是：目前 LLM 的架構方式，大多數(shù)是非確定性的。所以如果你的代碼有 bug，你很可能無法復現(xiàn)它。數(shù)據庫領域的人對此早就知道了。這叫做 Heisenbug（海森堡 bug）——不可復現(xiàn)的 bug，相對于 Bohrbug（玻爾 bug）——可復現(xiàn)的。Jim Gray 很久很久以前寫了很多關于這個的東西。我們顯然要重新審視所有這些問題。

【譯注】Heisenbug 這個名字來源于量子力學的"海森堡不確定性原理"——你一觀察它，它就消失了。Bohrbug 則來源于玻爾的確定性原子模型。這是 Jim Gray 在 1985 年提出的術語，用來描述軟件中兩類不同性質的 bug。

[30:02] 所以我認為，這是一個數(shù)據庫技術將對 Agentic AI 產生巨大幫助的領域——讓它實現(xiàn)"ACID-plus"或者不管最終叫什么。我認為這將是一件大事。

關于編程語言方面——事實已經證明它非常有用。Vibe coding 確實有效，在全新應用上效果最好——絕對正確。問題是 95% 的企業(yè)程序員不是在做全新項目，他們得處理已有的系統(tǒng)。

而且眾所周知，vibe coding 在代碼結構良好的情況下效果最好。但問題是，典型的企業(yè)系統(tǒng)不是這樣的。系統(tǒng)被更新、維護、打補丁、更新、維護、打補丁……最后變得太丑陋了，你只好扔掉重寫。

所以我認為，要想最大限度地利用 vibe coding 的優(yōu)勢，我們必須改變企業(yè)編寫軟件的方式。還有大量工作要做。

第四部分：2025 年行業(yè)回顧——并購與市場動態(tài)

[31:43] Andy Pavlo： 不僅僅是并購——今年數(shù)據庫領域風起云涌。我感覺今年的活動比去年還多。

先說說主要的收購案。最大的一筆可能是 Databricks 收購了 Neon，緊接著 Snowflake 收購了 Crunchy。所以 Postgres 生態(tài)有很多動作——我們稍后會談到。

IBM 買了兩家數(shù)據庫公司。 年初買了 DataStax——這是開發(fā) Cassandra 的主要公司。然后我記得這周剛宣布收購了 Confluent——Kafka 背后的主要公司。這些都是大手筆。

融資方面，ClickHouse、Supabase 都完成了大額融資。Databricks 又融了一大筆，因為他們總是在融錢，等著 IPO。Informatica 被 Salesforce 收購了。SkyDB 被 MariaDB 又買回去了——這個比較奇怪，因為他們去年好像是把它拆分成獨立公司的，今年又買回來了。

另一個大消息是 Fivetran 正在與 dbt 合并——我想這筆交易明年會完成。

所以是的，又是活動頻繁的一年。

[33:17] 關于倒閉的數(shù)據庫公司，我曾預測 2025 年會有更多公司失敗。大約兩年前有一份 Gartner 報告也做了類似的推測。但我能想到倒閉的只有兩三家：Voltron Data 幾周前宣布關閉；Fauna 五月份關閉；還有一家叫 MycaleDB 的中國 MySQL 托管公司今年早些時候倒閉了。

所以我預測錯了。我以為會有更多數(shù)據庫公司倒閉。數(shù)據庫公司的朋友們告訴我，其實今年相當不錯。這是積極的信號。當然確實有一些公司倒閉了，但沒有我想象的那么多。也許有些公司在苦苦支撐，誰知道呢。

有兩家公司被私募股權收購了：Couchbase 和 SingleStore。SingleStore 被一家叫 Vector 的私募公司收購了——他們幾年前買過 MarkLogic，所以有運營數(shù)據庫公司的經驗。但通常私募股權買下一家公司后，會讓它進入維護模式。希望 Couchbase 和 SingleStore 能挺過去。

[34:50] 說到今年的整體氛圍——顯然，Postgres 又是輝煌的一年。說到 Mike——我喜歡開頭介紹里他被列為 Postgres 的發(fā)明者，而我被列為一個網絡梗"數(shù)據庫學"的發(fā)明者。當然不是一回事，但我就當個榮譽收了。另外我們也可以加上圖靈獎——那更重要。

是的，Postgres 今年太瘋狂了。Databricks 買了 Neon，還買了 Mooncake——這讓他們有了讓 Postgres 讀寫 Iceberg 的能力。微軟剛剛發(fā)布了 Horizon DB——這是他們托管版的 Postgres，架構類似 Neon，采用存算分離，大概兩三周前宣布的——是他們一直在做的項目。

所以越來越多的 Postgres。

[35:42] 在開源數(shù)據庫領域，唯一可能算是 Postgres 競爭對手的是 MySQL——但那條船已經開走了。而且 Oracle 解雇了基本上整個 MySQL 開發(fā)團隊，只留下做 HeatWave 的——九月份的事。所以現(xiàn)在真的沒有什么大公司在全力投入 MySQL 的開發(fā)?；旧希?strong>Postgres 已經贏了。

這真是太令人興奮了。Postgres 的代碼庫——非常漂亮，前端很棒。后端有點問題，我寫過博客文章，我們也報道過這個。

Supabase 整合 OrioleDB 的努力非常令人興奮，因為那是多版本并發(fā)控制和其他機制的現(xiàn)代實現(xiàn)。Postgres 的那些機制——Mike，你們當年在 80 年代做的時候，根本沒有其他系統(tǒng)可以參考怎么做。所以希望他們能糾正你們當年在伯克利犯的錯誤。

[36:45] 總之，數(shù)據庫商業(yè)領域現(xiàn)在非常活躍。正如我說的，大量 vibe coding 應用正在生成，而 Postgres 是很多應用的默認選擇。

還有一件事要提——有兩個重大項目宣布要做分布式 Postgres。一個是 Supabase 的 Multigres，由發(fā)明 MySQL Vitess 的那個人領導——Vitess 后來被商業(yè)化為 PlanetScale。然后 PlanetScale 也宣布了一個叫 Naki 的項目，試圖做一個類似的分片、無共享版本的 Postgres。

有趣的是，這不是第一次有人嘗試做分布式 Postgres。2000 年代末、2010 年代初有一堆這方面的工作——Translattice、Greenplum，我記得華為也有一個項目。但對于 OLTP 工作負載，沒有人真正成功做出來。

我認為現(xiàn)在有足夠的能量，時機終于到了——你終于可以擁有一個真正可擴展的分布式 Postgres——不管是通過 Multigres 還是 Naki。這是我期待明年會出現(xiàn)的一個重大進展。

第五部分：Postgres 的未來與向量數(shù)據庫

[38:14] Mike Stonebraker： 說到 Postgres，我認為 Postgres 已經并將繼續(xù)統(tǒng)治世界。原因是所有主要云廠商都把寶押在了 Postgres 用戶接口上。Postgres 的線協(xié)議將無處不在。

他們要么選擇一個標準來開發(fā)，要么自己搞一套，而每一家都選擇了 Postgres 線協(xié)議。

我認為這是一個好選擇的原因是：很多年前 Oracle 收購了 MySQL，這讓社區(qū)對 MySQL 能否保持社區(qū)屬性產生了疑慮。

我覺得 Postgres 最令人驚嘆的是：這個系統(tǒng)不屬于任何企業(yè)——它由一群非常非常聰明的人運營，這些人在各種不同的地方工作。 所以你應該把 Postgres 看作開源本來應該是的樣子。它來自社區(qū)，服務于社區(qū)。

[39:46] 我還想談幾件事。第一，有人在聊天里提到了 Kumo。是的，我們看過 Kumo。Kumo 做的是預測，不是 Text-to-SQL，他們解決的是不同的問題。

另外，還有其他分布式 Postgres 類的東西。Greenplum 是一個，CockroachDB 是另一個，Yugabyte 也是。還有幾個我一時想不起名字了。但我認為，如果你還沒有把寶押在 Postgres 上，現(xiàn)在這樣做絕對是正確的。

[40:43] 我還想指出，Andy 和我?guī)啄昵皩懥艘黄撐?，叫做《What Goes Around Comes Around... and Around》（風水輪流轉……轉眼又一圈）之類的。你們都應該回去讀那篇論文，因為在我看來，那是對未來走向的絕佳預測。

【譯注】這是 Mike Stonebraker 和 Andy Pavlo 在 2024 年發(fā)表的論文，是對 2005 年經典論文《What Goes Around Comes Around》的續(xù)篇。論文回顧了數(shù)據庫領域的技術輪回，指出很多"新"技術其實是舊概念的重新包裝。

舉個例子，現(xiàn)在對向量索引或向量數(shù)據庫有很大興趣。那么，什么是向量數(shù)據庫？向量數(shù)據庫就是一堆關系型的 blob，加上一個圖結構的索引。

讀過 Frank McSherry 工作的人都知道，他清楚地表明：做圖檢索的最佳方法是——盡可能多地對圖進行編碼，把它放進內存，然后寫一個定制的查詢執(zhí)行器來處理。成功的向量數(shù)據庫似乎正是這么做的。

所以我的觀點是：去讀那篇論文吧，我認為它對未來走向的預見性很強。

[42:11] 主持人： 謝謝。我們會把論文鏈接和活動錄像一起分享給大家。

在我們轉向計算機科學的未來之前，快速問一個問題。你剛才提到向量數(shù)據庫，有不少關于向量數(shù)據庫的問題。Andy，你有沒有特別喜歡的向量數(shù)據庫？你對向量數(shù)據庫這個領域整體怎么看？

[42:36] Andy Pavlo： 我得小心措辭，免得得罪人。

我是說，我喜歡 Weaviate 的團隊。我沒用過他們的系統(tǒng)，但他們非常開放——開源的，文檔寫得很好——我能理解他們在做什么，比其他家可能更清楚一些。所有向量數(shù)據庫公司都來我們這兒做過演講，都在 YouTube 上。

這些向量數(shù)據庫公司需要想清楚的問題是——我?guī)啄昵昂?Weaviate 的 CEO 聊過這個——現(xiàn)在他們不是作為主數(shù)據庫在用。正如 Mike 說的，它們基本上是 JSON blob，里面放著向量嵌入，然后他們?yōu)檫@些建索引?，F(xiàn)在很多人把它們當成 Elasticsearch 來用——就像數(shù)據庫的第二份副本，你可以在上面跑最近鄰搜索，不干擾數(shù)據倉庫或常規(guī)的 OLTP 工作負載。

[43:48] 所以他們會走到一個十字路口，必須決定：是繼續(xù)做一個像 Elasticsearch 那樣的邊緣專用數(shù)據庫（這沒問題，有市場），還是想成為主數(shù)據庫。如果是后者，你就得開始添加 Postgres、CockroachDB 或 Oracle 提供的所有那些東西——事務、SQL 等等。

所以他們得決定怎么走。

不過我要說，挑戰(zhàn)在于：歸根結底，向量索引就是索引而已。所以對于像 Postgres 這樣高度可擴展的系統(tǒng)，你可以很快添加這些新的索引類型。

值得注意的是，當 ChatGPT 在 2022-2023 年左右成為主流時，然后 RAG 成了人人都在說的熱詞，大家意識到"噢，怎么做 RAG？你需要向量索引"——所有主要數(shù)據庫廠商在一年內都添加了向量索引。很多都利用了開源庫，比如 Meta 的 DiskANN 或 FAISS。添加這些東西并不是大工程。

相比之下，當列存儲出現(xiàn)時——那是相當根本性的工程改變，你必須改造系統(tǒng)來支持向量化執(zhí)行或列存儲。而向量索引，你可以直接塞進去，很快就能跑起來。

[45:23] 所以對我來說，這表明專門的向量數(shù)據庫系統(tǒng)的護城河沒那么寬。當然，它們做的事情肯定比 pgvector 好很多，但對于 99% 的人來說，用 pgvector 可能就夠了。

[45:46] Mike Stonebraker： 好，再補充兩點。

第一，花哨的向量索引基本上局限于內存。 所以如果你的問題超出了內存容量，性能會斷崖式下降。

第二，如果你的向量有大量更新，更新索引是個噩夢級的問題。 絕對是噩夢。

所以，如果你的數(shù)據是只讀的、規(guī)模不大，我認為向量索引沒問題。但如果你有大量更新，問題就復雜得多。而且如果你把索引和數(shù)據放在同一個主系統(tǒng)里運行，至少可以保持一致性。

[46:54] Andy Pavlo： 我是說，也不是那么一致，對吧？因為有時候這些索引你得重跑聚類算法，那意味著你得重新掃描所有數(shù)據。這和全文搜索的倒排索引面臨的挑戰(zhàn)一樣。它們可能有一個側緩沖區(qū)，你先吸收所有寫入，然后最終得運行代價更高的重建任務。

第六部分：GPU 數(shù)據庫與 IBM 收購

[47:21] 主持人： 謝謝。關于市場還有一個問題。Andy，你提到 Voltron 關門了。有人問這對 GPU 加速數(shù)據庫的未來意味著什么？

[47:33] Andy Pavlo： 好，我得小心點。

我對 GPU 數(shù)據庫一直持懷疑態(tài)度。2018 年我們有一個研討會系列，邀請了所有主要的 GPU 數(shù)據庫廠商來校園。我記得他們會炫耀各種驚人的數(shù)字，但那些只適用于能裝進 GPU 內存的數(shù)據庫。而且他們總是拿 Greenplum 來比——2018 年誰還在乎 Greenplum 啊？

所以我當時很懷疑，因為這看起來很小眾——你的數(shù)據必須足夠小才能裝進 GPU。

但發(fā)生變化的是——Voltron 在他們的論文項目或論文系統(tǒng)中展示的（雖然沒有找到產品市場契合點或商業(yè)可行性）——他們展示了如何快速地把數(shù)據從磁盤流式傳輸?shù)?GPU，讓 GPU 作為整個數(shù)據系統(tǒng)的加速器，而不用把所有東西都加載進去。

對我來說，這才是顛覆性的變化。不點名的話，我預計——你們應該預期——2026 年會有一些主要數(shù)據庫廠商宣布他們現(xiàn)在支持 GPU 加速。

[49:00] 主持人： 酷。還有一個市場問題。IBM 收購 DataStax（Cassandra）和 Confluent（Kafka 和 Flink）如何改變 IBM 在數(shù)據庫市場的地位？

[49:07] Andy Pavlo： 噢，Mike 當過 Informix 的 CTO。他可以講講 IBM，對吧？

我是說，DB2 仍然賺很多錢。IMS 可能還在收維護費。他們在這些老東西上仍然賺很多錢。今天的 IBM 不是 IMS 時代的 IBM，文化和產出都變了。

【譯注】IMS（Information Management System）是 IBM 在 1966 年推出的層次型數(shù)據庫，至今仍在一些大型企業(yè)的核心系統(tǒng)中運行，是"古董級"但仍在收費的產品。

所以，還得看吧？還得看他們會多深入地參與 DataStax 和 Confluent 的日常運營——是像 Red Hat 那樣讓他們作為衛(wèi)星公司獨立運作，還是快速整合成 IBM 整體咨詢服務棧的一部分。

[49:56] 對于 Cassandra 來說，Cassandra 源代碼的第二大貢獻者其實是蘋果。蘋果運營著世界上最大的——如果不是最大也是最大之一的——公開 Cassandra 集群。所以我認為 Cassandra 的管理權會沒問題的。

Kafka 的話，還得看。但 Jay 是個聰明人，在 Confluent，我相信他們會想出辦法的。

【譯注】Jay Kreps 是 Kafka 的創(chuàng)始人之一，也是 Confluent 的聯(lián)合創(chuàng)始人兼 CEO。

[50:43] Mike Stonebraker： 我認為你們都應該記住的是：IBM 基本上是一家服務公司和定制軟件開發(fā)公司。

很明顯發(fā)生的事情是 IBM 的客戶一直在要求這兩個系統(tǒng)。所以 IBM 有足夠的閑錢直接買下它們。

但我認為 IBM 有一個遺留硬件業(yè)務和一個巨大的遺留軟件業(yè)務。他們會繼續(xù)榨取這些業(yè)務的價值，直到這個電話會議上的每個人都安全退休。

第七部分：計算機科學教育與職業(yè)發(fā)展的未來

[51:33] 主持人： 好，讓我們換個話題，談談計算機科學以及 AI 如何影響課程設置——MIT、CMU 和其他地方——以及職業(yè)機會。

事實上，問答區(qū)已經有人問了：在 DBMS 公司找工作需要什么技能？Andy，也許你可以先談談 AI 如何影響了 CMU 的課程？

[51:58] Andy Pavlo： 我得說，現(xiàn)在沒人知道答案。 LLM 在回答考試題目、作業(yè)問題上好得驚人。

說個軼事，在我們的數(shù)據庫系統(tǒng)入門課上，第一個作業(yè)是：我們給你一個數(shù)據集，給你問題——有點像在解決 Mike 剛才說的那個問題——你必須寫 SQL 來回答問題。我們相當確定大多數(shù)學生在用 LLM。事實上，老實說，我在學期開始時鼓勵他們用 LLM——這是現(xiàn)在任何開發(fā)者都應該使用的工具，就像 GDB 或其他調試工具一樣。這就是世界的現(xiàn)狀。

但我要說，最終你必須理解基礎。這是卡內基梅隆一直在更加強調的——我們一直在這方面做得很好，但現(xiàn)在比以往任何時候都更重要。

[52:55] 回到 vibe coding 的話題。你可以讓 LLM 生成一堆代碼，但如果你不理解這些代碼試圖做什么、你試圖實現(xiàn)什么，你就會迷失。

所以我說，你應該學習的是計算機科學的核心基礎，這部分其實沒變。不管是用 JavaScript、C++、Rust 還是什么——語言和工具可能變，但基礎很重要。理解軟件在為你做什么。

[53:40] 關于在數(shù)據庫系統(tǒng)公司找工作需要什么技能——我認為目前沒有太大變化。理解系統(tǒng)基礎，理解硬件在做什么。

數(shù)據庫的美妙之處在于你必須理解一切——你會接觸到所有層面。所以你必須理解硬件想做什么、操作系統(tǒng)想做什么（或不想為你做什么）、網絡想做什么。理解所有這些。

然后我要強調的是：能夠與你沒有寫過的大型代碼庫互動、操作和理解。同樣，LLM 在這方面很有幫助。

[54:17] 還有調試——因為這個問題不會消失。LLM 還解決不了這個——我認為它們最終會做到。但理解復雜組件如何協(xié)同工作、相互交互、識別 bug、識別競態(tài)條件和其他問題——這個問題不會消失。這些東西只能通過實踐獲得。有很多方式可以做到。

我得說，現(xiàn)在的資源比 Mike 當學生時好太多了，比我當學生時也好太多?，F(xiàn)在有很多東西可以幫助人們理解數(shù)據庫系統(tǒng)在做什么。就是去做就行了。

[54:59] Mike Stonebraker： 我認為只要你來自一流大學，主修 CS 就會沒問題——正如 Andy 說的，你會學到如何利用所有可用的工具來提高生產力。

如果你從 Control Data Institute 或那類地方畢業(yè)，我認為市場會很糟糕——因為那里只教你寫代碼，而這不會是一個很有市場價值的技能，除非你超級超級超級聰明。

【譯注】Control Data Institute 是美國一家已經倒閉的職業(yè)培訓學校，曾經提供計算機相關的職業(yè)培訓課程。Mike 這里用它來泛指那些只教技術操作、不注重計算機科學基礎的培訓機構。

[55:48] 所以我認為，一流大學的 CS 專業(yè)招生總數(shù)可能會持平或下降一段時間。之后會怎樣，我不知道。

[56:00] Andy Pavlo： 但我還要說——一方面是的，因為 AI 幫助了很多事情，找工作會更難。但回到 vibe coding 那點，現(xiàn)在構建東西太容易了。

所以最終目標不一定是去 Google 或 Apple 或誰那里工作——你可以自己干。當然，我知道對很多人來說，由于不同的經濟狀況，說起來容易做起來難。但這也是令人興奮的一點——進入門檻大大降低了。

但同樣，我要說你仍然需要理解基礎。

第八部分：問答——核心數(shù)據庫基礎

[56:36] 主持人： 有一個關于基礎的問題。實際上有好幾個。人們在問：你認為最重要的數(shù)據庫內部基礎概念是什么？應該學習或掌握哪些來提升職業(yè)機會？

[56:52] Andy Pavlo： 我是說，一個——不是要推銷自己的東西——但我們把所有課程材料都放在 YouTube 上了，你可以做所有編程作業(yè)，做所有家庭作業(yè)，不用付 CMU 一分錢。所以都在那兒，盡管去學吧。

我覺得就是 ACID 那一套，對吧？原子性、一致性、隔離性、持久性。理解那是什么樣子——如何把數(shù)據從非易失性存儲移到內存中并進行交互。如何確保人們可以訪問他們的數(shù)據而不丟失任何東西。

這些是高層次的基礎。作為其中的一部分，你得理解算法復雜度。你得理解數(shù)據結構。你得理解優(yōu)化技術。你得理解并發(fā)控制。一點關系代數(shù)的集合論也總是有用的。

[57:54] 我會稱這些為基礎。然后正如我之前說的，數(shù)據庫系統(tǒng)的美妙之處在于：無論你對計算的哪個方面感興趣，你都可以在數(shù)據庫的背景下做。

如果你喜歡算法，那個領域有很多工作可以看。如果你喜歡網絡，你可以做那個。如果你喜歡編程語言，有一堆嘗試改進 SQL 或改變 SQL 的工作。

無論你對什么感興趣，你都可以在數(shù)據庫的背景下做。而且通常人們會為此付你很多錢。所以這就是為什么我對這個領域很看好。

第九部分：為什么選擇成為數(shù)據庫研究者？

[58:27] 主持人： 好，我們到整點了，最后一個問題。這是注冊表上有人問的。問題是問你們倆的：你們?yōu)槭裁催x擇成為 DBMS 研究者？

Andy Pavlo： Mike，你講講征兵的故事。

[58:46] Mike Stonebraker： 嗯，簡單的答案是：我讀研究生是因為當時有征兵制。 我的選擇是：去加拿大、進監(jiān)獄、去越南，或者讀研究生。這讓事情變得很簡單。

進了研究生院之后，我設法待到了 26 歲，然后軍隊就不要我了。

【譯注】這里說的是越南戰(zhàn)爭時期（1955-1975）美國的征兵制度。當時年輕男性面臨被征召入伍的風險，但研究生可以獲得延期服役的資格。26 歲之后通常不再被征召。

所以當我找到工作時——順便說一下，我認為我的論文完全是胡扯——當我到伯克利時，我說："好吧，我得想辦法拿到終身教職，得找個新東西來研究。"

[59:47] 對我產生巨大影響的一件事是伯克利給了我一個導師：Gene Wong（黃煦濤）。Gene 說："我們來看看這個——Ted Codd 剛剛寫了這篇開創(chuàng)性的論文。"那是 1971 年；他的論文 1970 年發(fā)表在 CACM 上。

于是我們開始研究數(shù)據方面的東西。Ted Codd 的東西簡單易懂，有一些數(shù)學基礎。另一個提案來自數(shù)據系統(tǒng)語言委員會（CODASYL），那是個低層次的圖結構的東西，完全是一團糟。

Gene 和我看著彼此說："怎么可能這么復雜的東西是正確的做法？"

所以這就定下了方向。很多是偶然，但很多是因為在你落腳的大學找到一個好導師。

【譯注】Ted Codd 是關系型數(shù)據庫之父，1970 年發(fā)表的論文《A Relational Model of Data for Large Shared Data Banks》奠定了關系數(shù)據庫的理論基礎。CODASYL（Conference on Data Systems Languages）則提出了網狀數(shù)據庫模型，在當時是 Codd 關系模型的主要競爭對手。

[1:01:06] Andy Pavlo： Mike 的故事比較傳奇。

我的情況是，我高中時被逮捕了，我不想進監(jiān)獄。 所以我查了聯(lián)邦監(jiān)獄管理局的統(tǒng)計數(shù)據，看什么類型的美國人進監(jiān)獄的比例最低？是有博士學位的人。

所以我想，如果我拿個博士，進監(jiān)獄的可能性就更低了。這就是我決定讀博的原因。

然后數(shù)據庫對我來說就是自然而然的事。我在一家不太正經的創(chuàng)業(yè)公司工作過，我們切換到 MySQL，我高中時就學了關系模型。太棒了。

Mike Stonebraker： 你應該講講你真的進監(jiān)獄那次。

Andy Pavlo： 呃，等等。我被逮捕的時候，我們認罪的是地方指控，沒走聯(lián)邦程序。所以我從來沒進過監(jiān)獄。

但我確實試過在監(jiān)獄向我妻子求婚。他們從來沒真的把我關進去，Mike，因為他們擔心一旦我進了監(jiān)獄，我就在他們的保險范圍內了。所以如果我出了問題或受傷，他們會被開除。所以我一直在外面的拘留區(qū)。

[1:02:25] 主持人： 嗯，好吧。不是我預期的答案，但非常精彩。

結語

[1:02:31] 主持人： 好了，我們得結束了。很抱歉沒能回答所有問題。

感謝 Mike 和 Andy，還有 DBOS 的 Jen，感謝你們幫助舉辦今天的網絡研討會，分享你們的智慧和經驗。

祝你們和所有在線的朋友節(jié)日快樂、新年快樂，期待 2026 年的活動再見！

正文完

觀點總結與老馮評論 Mike Stonebraker 的核心觀點 1. 對 LLM 做 Text-to-SQL 持悲觀態(tài)度

觀點摘要： 在真實企業(yè)數(shù)據倉庫上測試 LLM，準確率幾乎為零。原因有四：數(shù)據非公開、術語獨特、語義重疊、查詢復雜。他主張用 SQL 封裝數(shù)據源，讓查詢優(yōu)化器解決問題，而非依賴 LLM。

老馮評論： 這是對 Text-to-SQL 炒作的當頭棒喝。學術界和媒體吹捧 60-90% 準確率，但那是在玩具數(shù)據集上的成績。一到真實企業(yè)環(huán)境——MIT 數(shù)據倉庫這種用"Course 6.2"代替"計算機科學"的奇葩命名——LLM 立刻原形畢露。

這揭示了 LLM 的本質局限：它們是模式匹配器，不是推理引擎。企業(yè)數(shù)據的"暗知識"——隱性業(yè)務規(guī)則、歷史遺留術語——不在訓練語料里，LLM 自然束手無策。Mike 的"SQL 封裝 + 查詢優(yōu)化器"方案，本質是承認：結構化問題還得用結構化方法解決。

2. Agentic AI 需要 ACID，數(shù)據庫技術將大放異彩

觀點摘要： 當前 Agentic AI 是"只讀"的，很快會變成"讀寫"。一旦涉及更新操作（如在線購物流程），就需要事務語義——原子性、持久性、回滾能力。這正是數(shù)據庫技術幾十年來解決的問題。

老馮評論： 這是 Mike 最具遠見的觀點。當前 AI Agent 框架基本都是"樂觀執(zhí)行"——假設一切順利，出錯就重來。這在真實業(yè)務場景中是災難。

Mike 用自行車店的例子講得很清楚：查庫存→檢查信用→收款→發(fā)貨，每一步都可能失敗，失敗后必須回滾前序操作。這不是新問題——這就是 ACID 事務要解決的問題，只是披了層 AI 的皮。

我完全同意這個判斷：未來 1-2 年，數(shù)據庫技術（尤其是工作流事務、Saga 模式）將成為 Agentic AI 的核心基礎設施。DBOS 確實踩準了這個點。 這也是最近 PG 生態(tài)的各路 Agent DB 都在蹭 "Git for Data" 熱度的原因 —— 老馮在《Agent 需要什么樣的數(shù)據庫？[2]》中剛探討過這個問題。

3. Postgres 已經贏了，押注 Postgres 是正確選擇

觀點摘要： 所有主要云廠商都選擇了 Postgres 線協(xié)議。Postgres 的治理模式是"開源該有的樣子"——社區(qū)所有，沒有單一企業(yè)控制。Oracle 收購 MySQL 后社區(qū)失去信任，Postgres 因此受益。

老馮評論： 這是事實陳述，不是預測。Postgres 確實已經贏了——至少在開源關系型數(shù)據庫領域。AWS Aurora、Google AlloyDB、Azure Horizon DB、Supabase、Neon……所有人都在 Postgres 生態(tài)里玩。

Mike 作為 Postgres 創(chuàng)始人說這話，難免有"王婆賣瓜"之嫌，但客觀來說他沒說錯。MySQL 在 Oracle 手里確實涼了——今年 Oracle 裁掉了幾乎整個 MySQL 團隊。

不過老馮要補充一點：Postgres 贏了"協(xié)議戰(zhàn)"，但這也意味著 PG 發(fā)行版內戰(zhàn)即將打響。詳見《PostgreSQL 主宰數(shù)據庫世界，而誰來吞噬 PG？[3]》

4. 向量數(shù)據庫是"內存圖索引 + 關系型 blob"，護城河不寬

觀點摘要： 向量數(shù)據庫本質上是給 JSON blob 加了個圖結構索引。兩大限制：只能在內存里跑（數(shù)據大了性能斷崖）、更新索引是噩夢。

老馮評論： 這是對向量數(shù)據庫最精準的降維打擊。Pinecone、Weaviate、Milvus 炒得火熱，但 Mike 一句話戳破泡沫：你們做的不過是 Postgres 擴展能做的事。

事實也確實如此——pgvector 出來后，大多數(shù)場景根本不需要專門的向量數(shù)據庫。Mike 說"99% 的人用 pgvector 就夠了"，Andy 也表示認同。

我在兩年前《專用向量數(shù)據庫涼了嗎？[4]》一文中就預測過這一點。 向量數(shù)據庫公司的出路：要么做到極致性能（服務那 1% 的大規(guī)模場景），要么轉型成完整數(shù)據庫（加事務、加 SQL）—— 但后者意味著和 Postgres 正面硬剛，幾乎是死路一條。順帶一提，PG 生態(tài)里已經有擴展在做 DiskANN 了，在 NVMe SSD 上跑得相當不錯。

Andy Pavlo 的核心觀點 1. Vibe Coding 是真的，LLM 正在改變軟件開發(fā)

觀點摘要： Andrej Karpathy 創(chuàng)造的"vibe coding"概念正在成為現(xiàn)實。CMU 的課程項目現(xiàn)在幾乎可以完全由 LLM 解決。代碼質量和人寫的差不多——因為都是從同一個代碼語料庫學來的。

老馮評論： Andy 比 Mike 年輕 40 歲，他的樂觀主義反映了新一代研究者的心態(tài)。Vibe coding 確實在發(fā)生——GitHub Copilot、Cursor、Claude Code 的普及就是證明。

但 Andy 有一個關鍵前提經常被忽略：vibe coding 只對新項目有效。他自己也承認，95% 的企業(yè)程序員不是在做新項目開發(fā)。那些幾十年積累下來的屎山——被反復"更新、維護、打補丁"直到丑陋不堪——LLM 同樣束手無策。

所以 vibe coding 的真正影響可能是：新應用開發(fā)加速，但遺留系統(tǒng)維護依然是噩夢。這會加劇新舊兩極分化——用 AI 寫的新系統(tǒng)越來越多，老系統(tǒng)越來越沒人愿意碰。

2. 數(shù)據庫自動調優(yōu)需要 LLM + 專用算法的組合

觀點摘要： 專用調優(yōu)算法比 LLM 好 2-3 倍，但 LLM 快得多（15 分鐘 vs 50 分鐘）。未來方向是用"推理代理"來調度——可能調 LLM，可能調專用算法。

老馮評論： 這是 Andy 作為 OtterTune 創(chuàng)始人的復盤總結。OtterTune 失敗的原因他講得很清楚：形態(tài)問題——需要用戶授權連接、被動觀察而非主動干預。新方案通過 proxy 模式解決了這個痛點。

"LLM + 專用算法"的組合思路非常務實：LLM 擅長快速給出"差不多"的答案，專用算法擅長精雕細琢，用推理代理調度兩者，工程上完全可行。

不過我一直有個疑問：數(shù)據庫調優(yōu)真的需要這么復雜嗎？ 大多數(shù) Postgres 性能問題，有經驗的 DBA 看 10 分鐘就能定位。用 Pigsty 這樣的發(fā)行版，重要參數(shù)都已經自動調到對生產"足夠好"的程度——從"足夠好"調到"最優(yōu)"，邊際收益有多大？

真正需要自動調優(yōu)的場景是：(1) 沒有 DBA 的小公司；(2) 大規(guī)模多租戶場景。這兩個市場能養(yǎng)活一家公司嗎？OtterTune 的失敗說明，至少單獨做這個不行。Andy 現(xiàn)在的策略是 OEM 白標集成，比獨立產品務實得多。

3. 計算機科學教育的核心不變：理解基礎

觀點摘要： LLM 能解決 CMU 的作業(yè)，但學生仍需理解基礎——ACID、數(shù)據結構、算法復雜度、并發(fā)控制。語言和工具會變，基礎不變。

老馮評論： 老生常談，但在 AI 時代重提很有必要。Andy 說得對：如果你不理解代碼在做什么，LLM 生成再多代碼也沒用。

Mike 說得更直白：從 Control Data Institute（職業(yè)培訓機構）那種地方出來的人會很慘，但一流大學出來的人沒問題。 言下之意：編程正在分化 —— 頂尖人才設計系統(tǒng)，AI 寫代碼，頭部專家發(fā)揮幾十倍的效能，普通程序員直接出局。 殘酷，但可能是真實的未來。

4. 向量數(shù)據庫護城河不寬，pgvector 對 99% 的人夠用

觀點摘要： 向量索引就是索引，Postgres 一年內就加上了。向量數(shù)據庫要么做專用場景（二級索引），要么加事務/SQL 變成完整數(shù)據庫——后者意味著和 Postgres 正面競爭。

老馮評論： Andy 在這一點上和 Mike 完全一致——這也說明這是數(shù)據庫圈的共識 。老馮覺得，向量數(shù)據庫真的已經很無聊了。

總結

Mike Stonebraker 是 “老派智慧” 的代表 —— 50 年數(shù)據庫經驗讓他對技術炒作保持警惕。 他的悲觀主義不是因為不懂 AI，而是因為見過太多大風大浪后的一地雞毛了。 他對 Agentic AI 需要 ACID 數(shù)據庫 的判斷非常精準，這可能是這場對話中最有價值的洞見。

Andy Pavlo 是"新生代務實派" —— 既不盲目樂觀，也不固守舊觀念。 他承認 OtterTune 失敗的原因，調整策略做 OEM 集成； 他看到 vibe coding 的真實影響，但也承認只對新項目有效。 作為學者，他保持著難得的商業(yè)敏感度。

兩人的共識比分歧更重要：Postgres 贏了，向量數(shù)據庫過譽了，基礎比工具重要，AI 不會取代理解系統(tǒng)的人。

數(shù)據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群（搜pigsty-cc）