業務資料、向量、Agent 記憶放同一個庫：PostgreSQL 連年攀升的調查數字，說明了什麼

Stack Overflow 的開發者調查裡有一組變化值得回頭看。2018 年，使用 PostgreSQL 的受訪者約佔 33%；到 2024 年，這個數字已接近 49%。2025 年的調查中，它又連續第三年在資料庫類別拿下「最想使用」與「使用後最想繼續使用」的最高排名。這份調查於去年中旬發布，雖然它並非全球市佔率，各年度受訪羣體也不完全相同，但趨勢方向相當清楚：越來越多開發者實際把它裝進了生產環境。

資料庫這麼多，為什麼偏偏是它？答案不在規格表上的效能數字，而在現代應用到底需要存什麼。

做一個 RAG，才發現要存的不只向量

假設要做一套 AI 客服。使用者提問，系統去知識庫檢索資料，再交給模型回答。乍看找個向量資料庫就夠了。但往下做，問題接著來：這份資料屬於哪個客戶？是否過期？使用者有沒有權限查看？檢索出來的片段，能不能回溯到原文？

這些資訊全都要儲存，而且查詢時得一起考慮。pgvector 的官方文件展示的正是這種能力：為 PostgreSQL 加上向量型別與相似度檢索，同時保留原本的 SQL 查詢方式，可以加過濾條件，也可以關聯其他資料表。

換句話說，文件、文字片段、所屬客戶、版本和向量，可以放在同一套資料庫裡管理。這時 PostgreSQL 吸引人的地方就不只是「能存向量」，而是你原本就需要一個業務資料庫，現在它還能兼作知庫的儲存與檢索，團隊未必得再維護一套獨立系統。

當然，pgvector 不會自動把 PDF 解析好、切好片段、算出向量。它負責儲存與檢索，不是一整套 RAG 管線。

JSONB 處理的，是專案裡最常見的麻煩

另一種情境更日常：有些欄位很固定，有些欄位總在變。例如商品，名稱、價格、品牌可以設計成固定欄位，但充電器要記功率、耳機要記降噪模式、衣服要記材質，很難套用同一種屬性結構。

PostgreSQL 的 JSON 型別文件明確提到，關聯式資料與 JSON 可以互相配合。JSONB 並非把一段 JSON 原樣塞進去，它支援按內部欄位查詢，也能為合適的查詢建立索引。穩定的資訊放一般欄位，多變的屬性放 JSONB，這種混搭在 AI 應用裡同樣好用：模型回傳的結構化結果、工具參數、文件附加資訊，都能比照辦理。

這不代表它能取代所有文件資料庫，而是需求剛出現時，不必立刻換一套儲存方案。有一個前提值得記住：使用者編號、訂單金額這類關鍵欄位仍應認真設計。JSONB 方便，不代表整張表只留一個 JSON 欄位就是好設計。

Agent 的狀態與記憶，也需要落地的家

做 Agent 時，注意力容易都放在模型與工具呼叫上。但任務跑到一半等使用者審核怎麼辦？服務重啟後，之前執行到哪裡了？使用者上次交代的偏好，下次要不要記得？這些都需要持久化。

LangGraph 的官方記憶文件就提供 PostgreSQL 的接入方式：PostgresSaver 用來儲存執行檢查點，PostgresStore 儲存跨會話使用的記憶資料。這裡的機制要說清楚：並非 PostgreSQL 自己會「記憶」，而是框架把狀態與需要保留的資訊寫進資料庫，再按規則讀取與恢復。

結果是，一個 Agent 應用裡的使用者資訊、知識庫和工作流狀態，有機會用同一套基礎設施管理。對團隊來說這很實際：少接入一個系統，就少一份連線設定、少一套備份策略、少一條故障排查路徑。

為什麼它總能多做一點

看到這裡可能會問，PostgreSQL 怎麼什麼都能碰？關鍵在於它允許透過擴充套件增加新的資料處理能力。pgvector 是一例；PostGIS 擴充地理空間能力，處理位置、距離與區域關係；TimescaleDB 面向時間序列與事件資料，兩者的專案介紹都明確說明與 PostgreSQL 的關係。

向量檢索只是這個擴充生態裡比較受關注的一環。PostgreSQL 並非等 AI 熱潮來了才開始支援新需求，它的擴充架構早就把這條路鋪好了。

這也解釋了為什麼只用「效能好、事務可靠」來介紹它，總覺得沒講到重點。這些基礎當然重要，但開發者選型時真正在意的是另一件事：今天用它做業務，過幾個月要加搜尋、加知識庫，是不是還能接著用？能沿用既有的資料、工具與維運經驗，往往比重新引入一套系統劃算得多。

對正在評估技術棧的團隊，這組調查數字給的訊號很樸素：選資料庫時，與其問它現在能做什麼，不如問它兩年後還能替你接住哪些還沒出現的需求。PostgreSQL 的連年攀升，正是幾百萬開發者對這個問題給出的同一種答案。