讓 AI Agent 透過 MCP 快速建立隔離開發環境？比較 Self-hosted Supabase、Neon、Prisma Postgres 的成本與實務，給出分層建議：開發用 branching-native 資料庫，生產用 Supabase Cloud。
問題：Self-hosted Supabase 的多 Project 之痛
當你執行多個專案，並讓不同 AI Agent 透過 MCP 各自建立資料庫時，很快就會發現：Self-hosted Supabase 的 Docker Compose 部署只代表「一個資料庫」，沒有 Cloud 版本那種「一個帳號底下一堆 Project」的隔離概念。結果就是所有 Agent 的資料全部混在一起，無法區分專案邊界。
根本原因在於 Project 是各自獨立的 server instance，Cloud Dashboard 只是把多個 instance 呈現在同一個 UI 上。Self-hosted 只模擬單一 project，不支援多 organization 或多 project。
解決方案一：在單一伺服器上跑多套 Supabase Stack
如果你堅持自架，最常見的做法是為每個專案部署一套完整的 Supabase 容器群。你需要手動處理：
- 目錄隔離：每個專案獨立資料夾，各自持有
docker-compose.yml、.env、volumes/ - Port 衝突：每套使用不同的 port 區間（例如 project-a 用 8000/3000/5432，project-b 用 8100/3100/5433）
- Container_name 衝突：官方 compose 的 container_name 是硬編碼的，必須修改所有 service 名稱，連
vector.yml也要改 - 金鑰隔離：每個 instance 需要獨立的
POSTGRES_PASSWORD、JWT_SECRET、ANON_KEY、SERVICE_KEY，否則 A 專案的 anon key 就能打 B 專案的 API - Reverse Proxy：用 Traefik 或 Nginx 把不同子域名路由到對應的 instance
社群與官方討論的共識偏向：生產環境用各自獨立的 instance，以確保安全性與隔離。
資源成本
每個基礎 Supabase instance（PostgreSQL + PostgREST + GoTrue + Kong）約需 700MB–1GB RAM。8GB 伺服器可舒服跑 4–5 個生產專案。
解決方案二：使用 Coolify / Dokploy 等自架 PaaS
Coolify 能將「手動改 container_name、算 port、生金鑰、設 proxy」壓縮成「點幾下」，並內建 SSL、備份、Git 整合。但它有三個關鍵缺口：
- MCP 多實例連線無官方解：Coolify template 沒有開關啟用 MCP，且同一台伺服器上多個 Supabase 實例各自要曝露 /mcp 需要額外設定。官方建議僅透過 VPN 或 SSH tunnel 存取。
- Template 版本落後與升級風險：Coolify 的 Supabase template 使用過時版本，升級有時會弄壞服務。
- API 自動化受限：透過 API 建立 Supabase service 時無法指定 domain，自動化流程需多一道手續。
Dokploy 是較新的替代品，API 有完整的 OpenAPI spec，對 Agent 更友善，但同樣不解決 Supabase 多實例 MCP 連線的上游限制。
解決方案三：直接使用 Cloud 服務
如果 Agent 需要高頻開關、短命環境，自架的維運成本會快速超過 Cloud 帳單。以下是主流選項的比較：
Supabase Cloud
- 計費模型：月費 + usage，每個 project 最低 $25（Pro 方案），且 compute 24/7 計費，不 scale to zero
- 多環境成本：10 個 Agent 開發 project 每月 $250 起，幾乎全部浪費在閒置
- 適合：需要 Auth / Storage / Realtime 的生產環境
Neon
- 計費模型：純用量制，無月費下限，scale-to-zero 時僅 storage 費用
- 多環境成本：Free 方案支援 100 個 project，每個 project 100 compute-hours，開發環境近乎免費
- 適合：Agent 頻繁開關資料庫、branching 工作流
- 注意：always-on 生產環境每 1 CU 約 $77/月，Launch 方案無 HA
Prisma Postgres
- 計費模型：按操作次數計費，免費 50 個資料庫、每月 10 萬次操作
- 多環境成本：Agent 開發環境（低流量、大量資料庫）幾乎免費，但高流量生產環境極貴
- 適合：已使用 Prisma ORM 的 TypeScript 團隊，Agent 透過 MCP 管理資料庫
- 注意：cold query 延遲 2.1–3.2 秒，且部分 PostgreSQL 功能缺失
社群共識：分層，不要單選
對於 Agentic Coding 工作流，開發與生產的成本曲線形狀完全相反，建議採用兩層策略：
| 層級 | 推薦方案 | 理由 |
|---|---|---|
| 開發環境（高頻、短命、可拋棄） | Neon Free 或 Prisma Postgres Free | 近乎零成本，branching 支援秒級建立/銷毀，MCP 整合完善 |
| 生產環境（需要 BaaS 功能） | Supabase Pro | 包含 Auth/Storage/Realtime，定價可預測，社群成熟 |
| 生產環境（只需資料庫） | Neon Launch 或自架 Postgres | 避免 Supabase 的 BaaS 包袱，成本更低 |
一句話總結：Agent 開發環境用 branching-native 的資料庫（Neon / Prisma Postgres），生產環境用你真正需要的那個平台（Supabase 若需要 BaaS，Neon 若只需要 Postgres）。
實作建議：立即開始的具體步驟
- 今天就可以試：開一個 Neon Free 帳號，接上官方 MCP，讓 Agent 試著自己開 branch 做開發。成本為零。
- 同時評估 Prisma Postgres：免費 50 個資料庫，不需信用卡，驗證 cold query 延遲是否可接受。
- 兩週後再決定是否投入 Coolify 的維運成本。很可能你會發現 Cloud 方案已經解決 80% 的需求。
- 生產環境維持 Supabase Pro（如果需要 Auth / Storage / Realtime），不要為了統一而把生產搬到 Neon，那會失去 BaaS 的價值。
重要提醒：Agent 的權限邊界比基礎設施選型更重要
不論選哪條路，請務必：
- 不要將
service_rolekey 直接餵給 Agent。建立專屬 Postgres role，限制可操作的 schema 與 DDL 權限。 - 強制走 migration 檔而非直接 DDL。讓 Agent 產生 migration SQL，由 CI 或部署腳本套用。
- Sandbox 實例可以放寬，生產實例一律嚴格。