比較四種讓 AI Agent 取得隔離 PostgreSQL workspace 的方案：Neon branch、PGlite 內嵌、自架容器與多租戶引擎。涵蓋 REST、pgvector、MCP 介面整合與安全實務。
讓 AI Agent 廉價、安全、快速地取得一個完全隔離、且具備 REST、向量搜尋與 MCP 介面的 PostgreSQL workspace，是 2025 年 AI 基礎設施的關鍵挑戰。本文深入比較四條可行路線，並提供選型建議與安全實務。
問題的本質：四個約束的交叉
「一個 Agent 一個資料庫」在 2024 年之前不成立，因為傳統 Postgres 的 provisioning 成本遠高於一個 Agent 任務的價值。近兩年三項底層技術改變了局面：
- Copy-on-write / 分離儲存與運算 — 讓「開一個完整隔離的 DB」從分鐘級、按 GB 計費，變成秒級、只算 delta。
- Postgres 一站式化 — pgvector / pgvectorscale / BM25 進到 Postgres 本體，vector workspace 不再需要第二套系統。
- MCP 成為 provisioning 介面 — Agent 不只是查資料，而是自己開 DB、開 branch、跑 migration、丟掉 branch。
正確的拆解是：隔離邊界放在哪一層（branch / fork / database / container / process）→ 決定了成本、速度與安全模型，而 REST、vector、MCP 三個介面是分別補上去的。
四條可行路線
路線 A：託管 Postgres 的 branch / fork（目前的主流答案）
隔離邊界 = copy-on-write branch。這是「便宜 + 快 + 有真資料」三者唯一同時成立的組合。
- Neon 的 branch 是即時的 copy-on-write clone，不做完整資料複製，每個 branch 有自己的 compute endpoint。
- Tiger Data 的 Agentic Postgres 同樣以 copy-on-write block storage 讓資料庫可即時 fork，每個 agent 幾秒內拿到一份完整生產資料的隔離環境，只為變動的 block 付費。
- 安全模式：不要給 agent 直連 production，而是給它一個 fork，在 fork 內開放完整寫入權限，事後審查結果再 merge。
路線 B：自架容器（Postgres + pgvector + PostgREST + MCP server）
隔離邊界 = 容器 / microVM。最便宜（只有自己的機器成本）、最可控、無廠商鎖定，但 provisioning 速度取決於你的 orchestration，冷啟通常在數秒到數十秒，且 REST 層、MCP 層、憑證輪替、TTL 回收全部要自己組。適合已有 K8s / Nomad / Fly Machines 基礎的團隊。
路線 C：進程內嵌（PGlite）
隔離邊界 = process。PGlite 是編譯成 WASM 的 Postgres，打包為 TypeScript client library，可在 browser、Node.js、Bun、Deno 執行，不需安裝任何其他相依，gzip 後僅約 3MB，支援包含 pgvector 在內的多個 Postgres extension，且支援 memory:// 純記憶體、file:// 檔案系統、idb:// IndexedDB 三種儲存後端。
這條路線在 agent sandbox 的定位非常明確：AI coding agent 在 sandbox 裡寫程式時，sandbox 必須像 production 到足以讓工作有意義，同時又要夠便宜、夠快、可拋棄。代價是單使用者 / 單連線，且與應用程式同 process 執行，沒有網路層隔離，記憶體同空間——它隔離的是「資料」，不是「執行」。
路線 D：Agent 專用多租戶引擎（新興）
YugabyteDB AMP（Agentic Multitenant PostgreSQL）主打 scale-to-zero serverless，每個 agent 得到一個真實隔離的資料庫，起步僅需 a fraction of a core，並以 Resource Governance 把數百個突發、易閒置的 agent workload 打包在共享的分散式基礎設施上，同時提供 in-database RAG、vector search、MCP 2.0 與 database branching。屬於「fleet 規模」才需要考慮的選項，成熟度與生態仍在早期。
方案比較表
| 方案 | 隔離邊界 | REST | Vector | MCP | 成本模型 |
|---|---|---|---|---|---|
| Neon | Project / Branch (CoW) | 原生 Data API (PostgREST 相容) | pgvector + HNSW | 官方 remote MCP，OAuth | 分離儲存運算、scale-to-zero、只計 delta |
| Tiger Data Agentic Postgres | Service Fork (CoW) | 需自架 | pgvectorscale + pg_textsearch (BM25) | tiger mcp install |
只付變動 block |
| supabase/mcp | Project / Branch | PostgREST 內建 | pgvector | 官方 MCP + mcp-server-postgrest |
branching 需付費方案 |
| prisma/mcp | Database instance | 需自架 | pgvector（Postgres 內做 RAG） | local + remote 雙 MCP server | 用量計費、毫秒級 provision |
| electric-sql/pglite | Process (in-proc) | 需自架 | pgvector（動態載入） | 需自架 | 幾乎為零，僅記憶體/磁碟 |
| crystaldba/postgres-mcp | 不負責隔離（掛在既有 DB 上） | — | 支援 pgvector 語境 | 本體即 MCP，含 restricted mode | 自架 |
| neverinfamous/postgres-mcp | 不負責隔離 | HTTP/SSE transport | pgvector 一級支援 | Code Mode + OAuth 2.1 | 自架 |
| YugabyteDB AMP | 每 agent 一個獨立 DB | — | 原生 vector + in-DB RAG | MCP 2.0 | scale-to-zero，分數核起跳 |
三個介面怎麼補齊
REST 層
最省事的做法是用已內建 PostgREST 相容層的平台。Neon 的 Data API 直接針對 agent 場景設計：以 HTTPS 溝通，agent 用 fetch() 或 curl 即可，不需要任何 Postgres client library；JWT + RLS 確保每個 agent 只拿到它該有的存取權。即使資料庫 compute 在閒置時降載，REST 服務本身始終在線，且提供 per-branch endpoint——隔離邊界與 REST 邊界對齊。
自架路線則直接跑 PostgREST sidecar，以 JWT claim 對應 Postgres role，讓 RLS 成為真正的權限邊界。
Vector 層
- pgvector 是預設答案，覆蓋率最廣，HNSW 索引足以應付多數 agent memory / RAG 規模。
- 規模拉大時，Tiger 的 pgvectorscale 與 pgvector 並存，其 StreamingDiskANN 索引支援最高 16,000 維向量，text-embedding-3-large 這類大模型不需再降級為 halfvec。
- 混合檢索：pg_textsearch 實作 BM25 排序關鍵字搜尋，目前使用記憶體結構換取速度，磁碟分段與壓縮仍在開發中——選型時要留意成熟度風險。
MCP 層
分成兩類，不要混用：
A. Provisioning MCP（管平台） — Neon MCP server 把自然語言請求翻譯成 Neon API 呼叫，涵蓋建立 project、建立 branch、執行查詢與 migration。關鍵是其 migration 流程：prepare_database_migration 會從 production 資料建立即時 CoW branch，migration 先跑在該 branch 上，agent 驗證結果後再呼叫 complete_database_migration 合併回 main，出錯就丟掉 branch。Prisma 的 remote server 同理：負責 Prisma Postgres 資料庫的 provisioning、備份與連線字串管理。
B. Data-plane MCP（管單一 DB） — crystaldba/postgres-mcp 提供 unrestricted 與 restricted 兩種存取模式，restricted 限制為唯讀交易並施加執行時間上限。它處理了一個容易被忽略的攻擊面：LLM 可以透過發出 ROLLBACK 再開新交易來繞過唯讀交易模式，因此該專案使用 pglast 在執行前解析 SQL，拒絕任何包含 commit 或 rollback 的語句——這是判斷一個 Postgres MCP server 是否認真的試金石。
安全：真正的威脅不是「agent 刪庫」
大多數人以為最大風險是 LLM 刪改資料，因此有了唯讀模式、project-scoped 模式與 feature group 限制；但即使在唯讀模式下，prompt injection 仍是頭號問題。經典案例：攻擊者提交一張客服工單，內文夾帶指令要求 assistant 讀取 integration_tokens 表並把內容寫回工單；當開發者用 Cursor + Supabase MCP 以 service_role（繞過所有 RLS）去「列出最新工單」時，assistant 就把私密資料寫進攻擊者看得到的欄位。
因此「安全」在這個架構裡必須落在平台層與資料層，而不是模型層：
| 控制點 | 具體做法 |
|---|---|
| 隔離 | 一 agent 一 branch / fork / container；production 永遠不在 agent 的 context 內 |
| 權限 | JWT + RLS，而非 service_role；Supabase 的唯讀模式使用專屬的 supabase_read_only_user role |
| 工具面 | project scoping + feature group 白名單，只暴露該任務需要的 tool |
| SQL 面 | 執行前 AST 解析（pglast 式），拒絕 COMMIT/ROLLBACK 與 DDL |
| 資料面 | 用 masked / anonymized 資料集開 branch，而非真實 PII |
| 生命週期 | branch 帶 TTL 自動銷毀；合併回 main 必須人工 review diff |
建議的參考架構（依預算與規模分檔）
檔位 1：本機 / CI / 大量拋棄式任務（成本趨近零）
PGlite（memory://）+ pgvector extension + 自寫薄 MCP wrapper。每個 agent 一個 process，任務結束連磁碟都不留。適合單元測試、schema 實驗、短期 RAG。缺點是單連線、無網路隔離。
檔位 2：要真資料、要秒級、要 REST（主流建議）
Neon project → 每個 agent 一個 branch → 該 branch 的 Data API endpoint（JWT + RLS）→ Neon MCP 負責 provisioning、crystaldba/postgres-mcp restricted mode 負責 data plane。流程固定為：開 branch → agent 全權在 branch 內操作 → 人工 review diff → merge 或丟棄。若向量規模是主要瓶頸，同樣拓撲換成 Tiger Data 的 fork + pgvectorscale。
檔位 3：自主可控 / 資料不出境
Fly Machines 或 K8s Job 起 pgvector/pgvector image + PostgREST sidecar + postgres-mcp，前面掛一層 provisioning API 負責發 scoped JWT 與 TTL 回收。成本最低、鎖定最少，但你要自己承擔冷啟延遲與運維。
選型時最容易踩的三個坑
- 把 MCP 當成隔離機制。 MCP 是介面協定，不提供任何隔離。隔離必須來自 branch、container 或 process。read-only flag 只是減少一條攻擊路徑，不是邊界。
- 忽略 provisioning 延遲以外的延遲。 scale-to-zero 平台的冷啟差異巨大，建議自行 benchmark。
- 在 fork 裡放真 PII。 fork 的價值是「像 production」，但一旦 agent 讀得到真實使用者資料，lethal trifecta 就完整了（存取私密資料 + 接觸不可信輸入 + 對外通訊能力）。用 data masking 開 branch，是這個架構唯一便宜的解法。
結論
選擇哪條路線取決於你的核心約束：需要真資料且秒級隔離？選 Neon 或 Tiger Data 的 CoW branch。成本趨近零且可拋棄？選 PGlite 內嵌。自主可控且已有容器基礎？選自架容器。管理數百個 agent fleet？考慮 YugabyteDB AMP。無論哪條路線，記住安全邊界必須落在平台層與資料層，而非模型層。