AI 時代，PostgreSQL 憑什么贏了？

最近做了一場，聊了聊 PostgreSQL 與 AI 這個話題。主持人問了很多好問題，老馮也做了些回答。直播將在周二晚上放出，老馮這里把我（很多沒說的）觀點整理成文字稿，做了些展開和補充，希望對大家有所幫助。

PG 現在是什么狀態？

Q：PostgreSQL 當下在數據庫世界里是什么狀態？

PostgreSQL 已經成為數據庫世界的事實標準。它實現了類似 Linux 內核在操作系統領域的地位——整個生態正在不可逆地向 PostgreSQL 集中。引用 Andy Pavlo 在 CMU 數據庫研討會上半開玩笑的說法：“其他數據庫現在的處境，就像一個 55 歲老漢一覺醒來發現自己懷孕了。”

面對這種局面，大家都在向 PG 靠攏：原本屬于 MySQL 生態的廠商如 PlanetScale、Percona、TiDB 在嘗試轉型；RisingWave、GreptimeDB 等新數據庫從誕生起就默認使用 PG 兼容協議；各種業務軟件也都 default to PG。PostgreSQL 就是當下的數據庫之王。我不認為在未來一二十年里，這個位置會受到實質性的挑戰。

而真正精彩的戰斗，在 PG 發行版層面——無論你用的是 RDS / Aurora / Supabase 還是 EDB / CloudNativePG / Pigsty，底層雖然都是 PostgreSQL，但有著不同的風味和價值主張。這才是當下數據庫世界實質性競爭發生的地方。

PG 社區向 AI 的轉向

Q：過去一年，你觀察到 PostgreSQL 社區最明顯的“AI 轉向”信號是什么？

最明顯的信號是資本層面的。2025 年 PostgreSQL 生態發生了超過 12.5 億美元的收購——Databricks 10 億美金買了 Neon，Snowflake 2.5 億買了 Crunchy Data。這兩筆收購傳遞的信息很清楚：AI 時代，數據庫是值錢的基礎設施。PG 生態的公司幾乎拿下了數據庫領域的所有融資。

Neon 提供了一個值得關注的數據信號：他們 80% 的數據庫實例是 AI Agent 創建的。當然要注意，Neon 的用戶畫像偏向獨立開發者和 AI 早期采用者，這個比例不能簡單外推到整個數據庫市場。但趨勢方向是清晰的：數據庫的增量入口正在從人類開發者轉向 AI Agent。

技術層面的 AI 轉向信號也很密集：pgai、pg_vectorize 這類把 AI 能力直接嵌入 PostgreSQL 的擴展開始密集出現；Timescale 在推“Agentic PostgreSQL”；各種 MCP Server 讓 Agent 可以直接跟 PostgreSQL 對話。整個社區的敘事正在從 LLM 時代的“PostgreSQL 也能做向量檢索”，升級到 Agent 時代的“PostgreSQL 就是 Agent 的運行時環境”。

但我也要說明，很多對于 AI 的追捧與轉向，更多是發生在廠商與發行版的層面上。在數據庫內核層面，PostgreSQL 開發者社區依然保持著穩扎穩打、高度克制的狀態，沒有專門去湊熱點去做什么 AI / Agent 數據庫特性。例如在去年的 PG 大會上開發者投票環節，大家就對把 pgvector 向量擴展做進 PG 內核這件事興趣乏乏。這種克制本身就是一種信號——說明 PG 社區對“什么該進內核、什么該留給生態”有清醒的判斷。

PG 做對了什么？

Q：為什么 PostgreSQL 在 AI 時代突然被重新發現？它做對了什么？

PostgreSQL 沒有“突然”做對什么。它一直在做對的事——可擴展性。

這個觀點我在 2023 年的《》中提出，后來逐漸成為 PG 社區的共識，社區大管家 Bruce Momjian 在演講中也多次引申。PostgreSQL 30 年來堅持的那套可擴展架構，是其 Slogan 里“最先進”的真正體現。

舉個例子：大約 8000 行代碼的 pgvector 擴展，加上 170 萬行代碼的 PostgreSQL 內核，基本上覆蓋了大多數應用場景對向量檢索的需求。原因很簡單：如果你要從零做一個完整的獨立向量數據庫，你得先解決高可用、備份恢復、ACID 事務和各種通用數據庫基礎設施問題——這本身就值百萬行代碼；而做向量擴展的團隊可以站在巨人肩膀上，復用整個 PG 生態的能力，只需要專注幾千行核心業務邏輯。

在全文檢索、數據分析等領域，越來越多類似 pgvector 的擴展正在涌現，攻克一個又一個的數據庫細分場景。這種繁榮的擴展生態，正是源于 PG 極致的可擴展性。反觀 MySQL，即使到今天，社區版都沒有一個成熟的向量檢索能力，整體錯過了這一波 AI 紅利。

pgvector 與向量數據庫賽道

Q：pgvector 距離生產環境還缺什么？什么場景下你寧愿用專用向量數據庫？

pgvector 在 ChatGPT 火起來之前就出現了——2021 年剛出來時是個人項目，但 2023 年 AI 浪潮起來之后，Neon、Supabase、AWS 先后下場推動，巨量資源投入下早已達到專業水準。 去年 PolarDB 大會上有人整活現場 Bench pgvector 和 milvus，跑在英特爾 AMX 指令集上的 pgvector 比 Milvus 快了一倍，怪幽默的。

更有意思的是，pgvector 已經發展出了自己的子擴展生態——擴展的擴展。比如 Timescale 的 pgvectorscale 提供了 DiskANN 能力，國內 TensorChord 的 VectorChord 擴展在 IVF+RaBitQ 架構上支持流式索引更新和高級量化。pgvector 在 HNSW 索引的大規模并發更新場景下確實還有優化空間，這也正是這些子擴展在努力解決的方向。

光譜兩端可能還有一點細分生態位：如果你只需要一個嵌入式小向量庫，可以看看 Qdrant 這類輕量方案；如果搞萬億規模以圖搜圖、淘寶拍圖識物之類的場景，也可以評估 Milvus。但在光譜廣闊的中間地帶，現在 AI 新項目新應用的默認標配就是 PG + pgvector，這一點基本沒有爭議了。

AI 需要數據庫提供哪些能力？

Q：最近 Agent 非常火爆，也出現了各種“Agent Native 數據庫”與 Agent 記憶框架，怎么看？

坦率地說，現在市面上標榜“AI Native”或“Agent Native”的數據庫，大多數還停留在概念營銷階段。你問他們到底什么是 Agent Native，很難得到一個技術上站得住的回答。好像加了向量支持就算“AI Native”了——跟之前“Cloud Native Database”如出一轍。

在老馮看來，這個問題應該分兩層：核心需求與擴展需求。因為你無法枚舉 AI Agent 究竟需要哪些能力——今天需要向量檢索，明天可能需要圖查詢，后天又可能需要權重補丁，情緒向量——所以最好的策略不是顯式堆砌功能，而是提供一種“元能力”：當新需求出現時，社區可以通過擴展機制自然地將新功能加載進來。

PG 就是這種范式的集大成者。它可以通過 pgvector 提供向量能力，通過 AGE 提供圖查詢能力，通過 pg_search/pg_textsearch 提供 BM25 全文檢索能力，完整支持各類 JSON 操作，也支持 GIS、時序等各種數據模型。這些能力很多都是通過擴展加裝進來的。

在數據庫內核層面，其實不需要什么花里胡哨的 AI 原生能力，把一件事做好就行——在滿足安全可靠等非功能性需求的前提下，提供極致的可擴展性。功能性需求會自然在生態中成長出來。

這種方式演化出來的數據庫還有一個巨大的附帶優勢：解決了原來 Polyglot 多元持久化帶來的認知噩夢。以前你可能需要十幾個不同的數據庫拼接粘連才能解決的問題，現在可以在一個全棧超融合數據庫內部，用統一的 SQL 語言解決。這極大減輕了 Agent 和人類的認知負擔。

當然，同樣具有良好可擴展性的另一個數據庫是 DuckDB，SQLite 算半個。我認為具有這種特質的數據庫才能真正稱得上是“AI 時代的數據庫”。能夠提供敏捷并行探索、靈活組合功能、自由加載擴展、產出協同效應的數據平臺，才是未來。

Agent 需要數據庫提供哪些能力？

Q：有人說“數據庫是 Agent 的海馬體”，你怎么看？

海馬體是大腦中負責將短期記憶轉化為長期記憶以及記憶檢索的組件。如果非要類比大腦，數據庫里的向量查詢引擎勉強算是海馬體，但數據庫本身比這個大得多。數據庫包含存儲引擎、事務引擎、地理空間引擎、文檔引擎等各種組件，負責不同功能。記憶也分很多種：工作記憶、長期記憶、情景記憶、語義記憶。海馬體只是其中一個部分。

與其說數據庫是 AI 的海馬體，不如說數據庫是 Agent 的體外記憶系統（Exosomatic Memory）。就像人類發明文字和書籍來彌補大腦記憶的局限一樣，Agent 同樣需要一個持久化的事實記錄系統來彌補 Context Window 的局限。

當然，廣義上的“體外記憶”可以包括文件系統、對象存儲等所有持久化層。但數據庫之所以比文件系統更適合做 Agent 的核心記憶基礎設施，關鍵在于兩點。

第一是結構化的關聯查詢能力。Agent 在回溯記憶時，不僅僅需要“找到那段相似的話”（向量檢索），更需要將那段記憶與用戶畫像、歷史行為、時間線做 JOIN——這種關系推理是文件系統根本做不到的，卻是關系數據庫的看家本領。

第二是結構化的管控能力。多租戶權限隔離、細粒度的訪問控制——管理員有權限修改哪些記憶，團隊成員和外部不受信任的用戶可以影響哪部分記憶——這些都可以在數據庫的 RBAC 和行級安全策略（RLS）中優雅地解決。當然文件系統也有權限控制，但數據庫提供的是表級、行級、列級的細粒度管控，這在多 Agent 協作場景下是質的區別。

現在 Agent 記憶框架確實是一個百花齊放的狀態，但從技術壁壘的角度看，這些上層框架解決的更多是“記憶的組織策略”問題——什么該記、什么該忘、怎么檢索——而底層的存儲、檢索、事務、權限控制，最終還是要落到數據庫上。真正有持久壁壘的，是底下的數據庫本身。

PG 18 有什么 AI 相關特性？

Q：PostgreSQL 18 為 AI 準備了哪些關鍵特性？

PG 18 有兩個特性跟 AI 關系密切。我認為最重要的是數據庫克隆（Database Cloning）。這個功能可以基于 Copy-on-Write 機制瞬間克隆一個大型數據庫，且不占用額外存儲。你可以克隆多個副本，讓 Agent 在克隆副本上做修改——這些修改都是增量的。等確認無誤后，再把修改應用到生產數據庫上。

這給了 Agent 一種“反事實推演”的能力。人腦也有這種機制：做一件事之前先在腦中推演可能的后果，謀定而后動。Agent 不可能也不應該直接修改重要的生產數據庫，數據庫克隆給了它“先驗證、再實施”的安全前提。

更進一步說，這給了 Agent 并行探索的能力——fork 多個分支、并行嘗試、擇優合并，類似代碼世界里的 Git。現在 Coding Agent 通過 Git 來管理代碼倉庫狀態，通過 worktree 來開分支并行探索，而數據庫克隆等于在最棘手的數據層也補上了分支探索的能力。

OAuth 認證

另一個有趣但被低估的特性是——PG 18 支持OAuth 認證登錄。未來當我們進入多 Agent 網絡、Agent 平臺經濟時代，Agent 可以直接通過 OAuth 認證登錄數據庫，這帶來了很多想象空間。

已經有了一個早期概念驗證案例——看看 Moltbook（小龍蝦社交廣場）——本質上就是一個 Supabase 實例，PG 套 RestAPI，Agent 直接連到數據庫上讀寫數據進行交流。這個模式的終局可能是這樣的：一個數據庫放在那里，它本身就是一個應用平臺。Agent 來到這個數據庫，每個 Agent 對應一個用戶。PG 18 支持 OAuth 了，Agent 直接登錄，擁有自己的權限和私有狀態表，也可以去公共廣場表里發表信息。

我說“可能”，是因為目前這只是一個極簡原型。從 Moltbook 這樣的社交實驗到真正的“數據庫即業務架構”，中間還隔著操作規約（Convention）的缺失：Agent 如何發現一個數據庫中有哪些核心表？語義如何自描述？如何做細粒度的資源配額管理？這些問題還沒有標準答案。但 PG 已經提供了底層基石：身份認證、并發控制、訪問控制、事務隔離——這些都是多 Agent 協作的必要條件。

Agent 的數據庫選擇權

Q：在 Agent 時代，數據庫的競爭維度會發生什么變化？大家會怎么選型？

這是一個被嚴重低估的趨勢：數據庫的選擇權正在從人類轉移到 AI Agent。

有些用戶完全不懂數據庫，他們只是跑 Claude Code，然后 Agent 搜索文檔、評估方案，自主完成了整個數據庫選型和部署。這引出了一個有趣的問題：AI Agent 通過什么來“選擇”數據庫？

我的直覺是可檢索的文檔。Agent 在做決策時會參考大量的文檔、最佳實踐和社區問答。如果某個數據庫的文檔最全、社區最活躍、最佳實踐覆蓋度最高，Agent 就會更傾向于推薦它。

這意味著文檔質量和社區密度可能會變成比性能更重要的競爭維度。

這不僅僅是理論推演。我自己的數據就有一個有趣的現象：Pigsty 文檔站的 Cloudflare 流量在過去一段時間以驚人的速度上漲。頁面上的人類活躍用戶也就不到十萬（Google Analytics），但月 PV 達到了 5000 萬量級。這些流量中很大一部分來自 AI Agent——不少新增用戶只是讓 CC 弄個 PG，CC 就自己把 Pigsty 拉起來了。而 Pigsty 目錄里的 CLAUDE.md 放了整個文檔索引，Agent 需要什么就會自己去查。

這就構成了一種 AI 時代的雪球效應：文檔質量高 → Agent 更傾向于推薦你 → 更多人通過 Agent 使用你 → 產生更多實踐反饋 → 更多最佳實踐文檔 → Agent 更“懂”你，推薦更精準。正反饋循環，贏家通吃。

PG 在這個維度上有巨大的先發優勢——它擁有所有數據庫中最全的文檔和最活躍的社區。這可能是未來數據庫競爭中最重要、也最反直覺的維度。

DBA 會被 AI 取代嗎？

Q：Agent 能做數據庫選型，那能替代 DBA 嗎？

DBA 這個群體其實包含兩種截然不同的角色：

第一種是 DA / 數據架構師 / 數據管理者很難被替代。他們的核心價值不僅在于判斷力（Judgment），更在于問責能力（Accountability）——說白了就是能背鍋。就像有了 AI 做賬，最后還是得有個會計簽字。在涉及數據安全、合規、架構決策的場景下，人類專家的判斷和擔責是不可替代的。

第二種是運維型 DBA（Operational DBA）。這個角色面臨的替代壓力非常大，最后可能只有背鍋價值了。在能力覆蓋上，AI 可能已經做到了七八成。

這里有一個微妙的結構值得注意：AI 沖擊更多的是價值曲線的中段。頂尖專家受沖擊較小，因為他們是 AI 的駕馭者，提供著不可替代的訓練信號和決策判斷；剛入行的新人則是一張白紙，反而可以直接拿著專家經驗蒸餾出來的工具快速達到中級水準。被擠壓最狠的反而是中間層——那些靠積累的操作經驗吃飯、但還沒有形成不可替代判斷力的人。

但 DBA 有一個結構性優勢常被忽略：AI 對價值曲線中段的沖擊，在前端和后端領域遠比在數據庫領域劇烈。原因很簡單：AI Agent 自己就需要使用數據庫。在傳統 IT 技術棧中，數據庫始終是核心——DBA 已經對數據庫有了深入理解，他們利用 AI Agent 去完成前后端工作，比前后端工程師利用 AI 來折騰數據庫要容易得多。

DBA 雖然也受沖擊，但在這波浪潮中，轉型的機會可能比很多技術崗位更大。DBA 可以利用這種結構性優勢，以更快的速度把自己武裝成“全棧”。當然，這不是免死金牌。前后端工程師用來搞數據庫的的門檻也在快速降低。DBA 的結構性優勢是一個時間窗口，不是一個永久護城河。能不能在這個窗口期完成轉型，因人而異。

新入行的工程師怎么辦？

Q：初中級 DBA 被 AI Agent 取代，你有什么對入行新人的建議？

AI Agent 帶來了一個嚴峻的問題：它正在把從學徒晉升到專家的傳統通道切斷。

以前的路徑是跟著師傅學三五八年，在實戰中培養直覺，最終成為專家。但現在這條路走不通了——因為中間層崗位在消失，新人缺少實戰環境。那些能寫出來的顯性知識會被 AI 吞噬，而真正讓專家不可替代的體感知識、隱性知識，只能在具體環境中沉淀，而現在這個環境對新人關閉了。

我給新人的建議是去學點真本事——軟件工程能力 + 基礎設施知識，向下扎根，向上擁抱。

軟件工程能力，不是指“會寫代碼”，而是指：怎么把一個模糊的需求變成可執行的方案？怎么設計一個可維護的系統？怎么在 AI 的幫助下構建復雜項目？這是一整套新的工程實踐，和“會用 AI 聊天”是兩回事。去學習如何駕馭 Claude Code 這樣的 Coding Agent，掌握像 BMAD 這樣的方法論框架，學會用 AI 做工程而不只是做對話。

基礎設施知識，是指那些“離金屬近”的東西：操作系統、數據庫、網絡、存儲。這些東西變化慢、護城河深、受 AI 沖擊小，在訓練數據里稀疏但在生產里致命。AI 應用也好、Agent 也好，最后都得跑在基礎設施上。找一個能讓你直接觸摸底層、看懂整個生態全貌的場域——比如深入 PostgreSQL 本身，而不是在中間件的抽象層里打轉。

當你把這兩端打通——向下理解基礎設施，向上駕馭 AI 生產力——你就是新時代的“全棧”。

小結

老馮的個人觀點：PostgreSQL 已經成為 AI 時代數據世界的最大贏家。

數據庫這個行當已經存活了半個世紀。從層次模型到關系模型，從大機到分布式，從本地到云端，每一次范式轉移都有人宣布“舊世界已死”。但真正死掉的從來不是數據庫本身，而是那些試圖用一種固定形態去回答所有問題的產品。

這就是技術世界最大的反諷：當所有人都在追逐“下一個新東西”的時候，真正撐起新時代的，往往是最樸素的基礎設施。但 PostgreSQL 并不只是單純的基礎設施 —— 它是能為上層演進提供敏捷適應力的基礎設施。一個高度穩定克制的內核，加上一個繁榮瘋長的擴展生態，調和兩者的魔法叫做可擴展性。

從軟件時代的 GIS，到互聯網時代的 JSON 與全文檢索，再到 AI 時代的向量——正是這種特質，讓 PG 在每一次范式轉移中都不是被淘汰的舊物種，而是承接新物種的底座。

AI 時代最稀缺的是信任。Agent 要信任它操作的數據不會丟，它做的修改可以回滾，它的權限邊界是清晰的。這些聽起來很無聊的特質——持久性、一致性、隔離性——恰好是關系數據庫打磨了五十年的東西。而當新的需求出現時，不需要重寫 PG，只需要長出一個新的擴展。

PostgreSQL 走到今天，不是因為它在任何單項上做到了最好，而是因為它從一開始就沒有試圖定義“最好”應該長什么樣——它把這個定義權交給了生態，交給了 pgvector 的開發者、各種發行版的作者，以及未來某個我們還不知道名字的擴展。

這就是 PostgreSQL 最大的底氣：它不需要預見未來，只需要讓未來長在自己身上。

利益相關：老馮是 PostgreSQL 發行版 Pigsty 的創始人，觀點帶個人偏好，請讀者自行校準。

數據庫老司機

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

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

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403