為什么PG將主宰AI時代的數據庫

Agent 時代，軟件架構的底層邏輯變了。

過去十年，我們為了遷就人類團隊的協作邊界，搞出了微服務和“多元持久化”（Polyglot Persistence），把系統拆得七零八落。 但在 AI Agent 崛起的新范式下，這種碎片化架構正在成為一種昂貴的“技術負債”。最稀缺的資源不再是存儲或算力，而是 LLM 的注意力帶寬（Context Window）。

微服務帶來的復雜度與碎片化，正在向 AI Agent 征收巨額的“認知稅”。 而這劑毒藥的解藥，只有 PostgreSQL。本文就來聊聊，為什么 PG 會成為 AI 時代的“數據庫之王”。

—— 老馮在 “第八屆中國 PG 生態大會” 上的閃電演講

在傳統的“最佳實踐”中，我們習慣把數據拆得支離破碎：MySQL 存交易，Redis 做緩存，Mongo 存文檔，Elasticsearch 搞搜索，Milvus 存向量。

這種設計理念被稱作“多元持久化”（Polyglot Persistence） —— 在單個系統中使用多種數據存儲技術，以滿足不同的數據存儲需求

看上去 “用專業的工具做專業的事”很美好，然而這為 AI Agent （以及人類工程師）帶來了一個高度對抗性的環境。 Agent 主要在上下文窗口的邊界內運作，這個有限的緩沖區——無論是 8k、128k 還是 1M Token——就是 Agent 的全部：短期記憶、工作草稿、接口定義，全部擠在這里。

想象一個典型的跨域查詢任務：“找出購買了 X 商品并訪問過 Y 頁面，且工單情緒負面的用戶”。在多元持久化架構下，Agent 必須經歷一場“由于數據孤島導致的消耗戰”：

1.加載驅動與 Schema（燒錢）：Agent 必須把 MongoDB 的語法、ES 的 DSL、Neo4j 的 Cypher，以及各端的 Schema 定義統統塞進上下文。每一個用于解釋 API 的 Token，都是從核心推理能力中竊取的資源。2.編寫膠水代碼（高危）：Agent 被迫充當“分布式調度器”，編寫 Python 代碼去連接三個不同的系統，處理網絡超時、認證失敗和版本不匹配。3.應用層 Join（低效）：數據在不同系統間搬運，Agent 被迫在有限的內存里做數據清洗和連接。

這種“乒乓（Ping-Pong）”架構不僅效率低下，更會導致上下文過載。 將所有工具定義塞進一個巨型 Agent 會迅速耗盡預算，當無關的 Schema 和中間數據填滿窗口，LLM 的推理能力會被鎖死天花板，直接導致“幻覺”飆升。

上下文經濟學偏愛“小而美”的工具，厭惡龐雜的異構系統。

PostgreSQL：零膠水架構

解藥是什么？是大一統。

我們需要一個能在一個連接、一種方言里解決所有問題的“數據操作系統”。PostgreSQL 憑借其獨步天下的擴展性（Extensibility），早已超越了關系型數據庫的范疇，進化為全能的數據平臺。

PG 的哲學很簡單：把復雜性下推（Push-down）到數據庫內核，讓 Agent 保持輕量。

全棧數據融合：三位一體

PG 的擴展生態系統有效吸收了專用系統的能力：

在 PG 生態中，你不需要為了一個新特性去引入一個新的數據庫組件：

對 Agent 而言，這意味著語義宇宙的統一。它不需要在 SQL、DSL 和 API 之間精神分裂。

更重要的是混合檢索（Hybrid Search）的民主化。你可以在一條 SQL 中，同時完成精準過濾、全文關鍵詞檢索和向量語義檢索。這不是三個系統的拼湊，而是一個引擎內部算子的優雅流水線。

把數據邏輯收斂到單一的、符合 ACID 的 PostgreSQL 引擎中，Agent 不需要關心分布式事務的最終一致性，不需要處理跨服務的數據競爭。事務要么提交，要么回滾。這 種確定性讓 Agent 能將數據層視為一個可靠的原子原語（Primitive），而不是一個充滿不確定性的分布式混沌系統。

FDW：零膠水架構與位置透明

如果你確實有外部數據需要訪問，又怎么辦呢？PG 的 外部數據包裝器（FDW） 是 Agent 的“上帝視角”。

通過 FDW，Postgres 可以掛載萬物：DuckDB、MySQL、Redis、Kafka、S3 上的 CSV，甚至是 Stripe 的 API 或系統監控指標。

對于 Agent，這實現了完美的位置透明性（Location Transparency）。 Agent 只需要執行 SELECT * FROM sales_data。 它不知道，也不需要知道這份數據到底是躺在 S3 冷存儲里，還是在 Snowflake 的數倉里。PG 負責了所有的協議轉換和數據搬運。

這就是“零膠水”架構的終極形態：Agent 不再需要寫幾百行 Python 代碼來做 ETL，它只需要發送一段高密度的 SQL 指令，聲明自己想要的東西。

Supabase 甚至專門做了一個 Rust FDW 框架 wrappers，以及一個專門的網站：fdw.dev ，提供幾十個將外部數據接入 PG的包裝。

存儲過程：服務器端工具箱

PostgreSQL 支持用 Python、JavaScript、Rust 等二十多種語言編寫存儲過程。這不僅是功能，更是架構上的降維打擊：

?Token 節省：復雜的業務邏輯（RAG 流程、數據清洗）固化在數據庫函數中，不再占用寶貴的 Prompt 空間。?安全性與沙箱：Agent 調用的是封裝好的函數（Tool），而不是裸奔的 SQL，權限邊界清晰可控。?性能：邏輯貼著數據跑，消除了網絡 IO 開銷 —— 通常是最大的性能瓶頸

接口標準化：psql 即 IDE

PG 的 SQL 方言 ，libpq PG線纜協議幾乎是所有 LLM 訓練數據中都覆蓋的知識。GPT-4 和 Claude 對寫 PG 風格的 SQL 駕輕就熟。

通過在 Postgres 上標準化，我們為 Agent 提供了一個確定性的環境。 你甚至不需要 MCP，pymongo、redis-py、neo4j-driver 這些驅動都可以扔掉了。 命令行里的一個 psql + 連接串就可以開始工作，接口定義簡化為一行： postgresql://user:password@hostname:5432/db

僅憑這一個連接，Agent 就能利用 pg_net / pg_curl 聯網，利用 FDW 讀寫萬物，利用 SQL 編排邏輯。甚至是執行 Shell 命令。

psql 提供 Bash 的功能超集，天然適合成為 AI Agent 的下一個首選執行環境。

結論

上下文窗口經濟學決定了軟件架構的未來。 在智能按 Token 定價、受 Prompt 大小限制的世界里，架構簡潔性是終極優化目標。

多元持久化曾是技術能力的象征，現在已成負債——摩擦、延遲、Token 浪費的源頭。它割裂 Agent 的現實，迫使 Agent 將認知資源浪費在膠水代碼上，而非價值創造。

PostgreSQL 配備 pgvector、pg_net、postgres_fdw 等擴展生態，提供了統一、可編程、"主動"的環境——一個真正的 Agent 操作系統。它允許 Agent 通過單一標準接口（SQL）進行推理（Vector）、行動（Curl）和觀察（FDW）。

Databricks 和 Snowflake 的巨額收購是最終驗證：AI 的未來是 Agentic 的，而 Agent 的數據庫是 PostgreSQL。