InsForge：為 Vibe Coding 而生的 Supabase

老馮最近發現了一個有意思的項目：InsForge。口號是——為 AI 編程設計的 Supabase。

Apache 2.0 開源，GitHub 約 2000 Star，核心技術棧是 PostgreSQL + PostgREST + Deno + TypeScript，5 個容器就能跑起來。老馮收集大寶貝的毛病又犯了，趕緊把它加入到 Pigsty 代自建全家桶里來（隨下個版本一起發布）。

這個項目觸及了一個真實的痛點，值得展開聊聊。

Vibe Coding 的"最后一公里"

2025 年以來，"Vibe Coding" 已經從一個 meme 變成了真實的生產力。你打開 Cursor，用自然語言告訴 Agent："給我做一個帶評論功能的博客"，十分鐘后一個漂亮的 React 前端就出來了。

然后呢？

前端搭好了，數據往哪存？用戶怎么登錄？文件傳到哪里去？ Agent 對著后端基礎設施一臉茫然。你得手動去開數據庫，配 RLS 策略，搞 OAuth，部署 Serverless Function……一頓操作猛如虎，一看時間凌晨三點半。

這就是 Vibe Coding 的悖論：AI 能在幾分鐘內生成任意復雜的前端代碼，卻搞不定后端那一坨配置、認證、存儲的苦活。 不是 Agent 不夠聰明，而是傳統后端服務壓根不是為 Agent 準備的。正如 Vibe Coding 之父 Andrej Karpathy 說的，他只花了一天把那個算熱量的小程序寫出來，卻花了整整七天才讓它在服務器上跑起來。

InsForge 想解決的，就是這個"最后一公里"。老馮的 Pigsty 之前其實也有過類似的原型——目錄里寫好 CLAUDE.md，你用 Claude Code 說"給我做一個應用"，它也會用 PostgreSQL 給你搞出來。現在好了，有個更完整的開源方案出來了，也省老馮的事兒了。

它到底是什么？

從技術架構上看，InsForge 提供六大后端原語：

另外最近還加了站點部署（Site Deployment）和郵件等實驗性功能。

聽起來跟 Supabase 差不多？差別在架構層面。

關鍵差異：Semantic Layer

InsForge 的核心設計是在 AI Agent 和后端原語之間加了一層語義層（Semantic Layer），通過 MCP 協議暴露給 Agent：

這層語義層做三件事：暴露上下文——Agent 通過 MCP 直接"看到"后端的表結構、Schema、RLS 規則；操作原語——Agent 直接通過 MCP 工具調用來建表、配 OAuth、部署函數，不需要你在 Dashboard 上點來點去；檢查狀態——執行完可以查日志、驗證結果，形成閉環。

用他們的話說，這叫 Context Engineering for AI Agents。

實際體驗

以自建部署為例：

git clone https://github.com/insforge/insforge.git
cd insforge
cp .env.example .env
docker compose -f docker-compose.prod.yml up

跑起來一共 5 個容器：PostgreSQL 15（ghcr.io/insforge/postgres:v15.13.2）、PostgREST v12.2、InsForge 主服務、Deno 2.0 運行時、Vector 0.28 日志收集。跟 Supabase 自建動輒十幾個容器比起來，確實清爽。

然后打開 http://localhost:7130 的 Dashboard，按頁面引導連接 MCP Server 到你的編輯器。也可以直接命令行裝：

npx @insforge/install --client cursor \
--env API_KEY=your_key \
--env API_BASE_URL=http://localhost:7130

目前支持 Cursor、Claude Code、Windsurf、Cline、Roo Code、Trae 等主流 AI 編輯器。

接下來就可以在編輯器里對 Agent 說："幫我創建一個用戶表，包含 email 和 name 字段，然后搞一個注冊登錄流程"。Agent 會自動通過 MCP 了解 InsForge 的能力、創建表、配置認證、生成前端代碼。整個過程你不需要打開任何 Dashboard、不需要手動配置任何東西。

老馮的看法

InsForge 做對了一件事：把"Agent 能不能理解后端"作為第一優先級來設計。 傳統 BaaS（Supabase、Firebase）是為人設計的，Dashboard 做得再漂亮，對 AI Agent 來說也是不可見的。Agent 需要的是結構化的 API、一致的響應格式、可檢查的狀態——InsForge 圍繞這個需求重新設計了接口。

當然也有一些局限性：

?2025 年 7 月成立，團隊 5 人，還在項目早期階段?底層還在用 PG 15（老馮這邊弄上 PG 18 了）?文檔偏薄，高級自建場景（HA、備份、安全加固）基本沒覆蓋

說到底，它的組件（PostgREST + Deno + JWT）單個來看都不新，核心壁壘是那層 MCP 語義層的工程實現。

但從趨勢上看，“Agent-Native Infrastructure” 這個方向是存在的。當越來越多的代碼由 AI Agent 寫出來的時候，后端基礎設施怎樣更好地服務于 Agent 而不是人類在 Dashboard 上點鼠標，這是一個值得認真思考的問題。

架構拆解：簡化版 Supabase

Insforge 策略很清楚：砍掉 Supabase 里的重量級組件（GoTrue、Realtime Elixir Server、Kong、Supavisor、imgproxy），全部用 TypeScript 重寫，換來極簡部署。對于 Vibe Coding 的典型場景——快速原型、個人項目、黑客松——夠了。

最關鍵的是，PostgreSQL 仍然是絕對的核心。所有數據存在 PG 里，所有 API 從 PG Schema 自動生成，認證信息加密存儲在 PG 中，RLS 策略在 PG 層面執行。InsForge 本質上就是一個圍繞 PostgreSQL 構建的、面向 AI Agent 的薄封裝層。

納入 Pigsty 全家桶

說到 PostgreSQL 就得提 Pigsty。

老馮看完 InsForge 架構之后，第一反應是：它最大的弱點恰好是 Pigsty 最大的強項。InsForge 自帶的 PostgreSQL 只是一個單節點 Docker 容器，沒有高可用、沒有監控、沒有自動備份。而 Pigsty 管理的 PG 集群天生就有 Patroni HA、VictoriaMetrics 監控、pgBackRest 備份、連接池、負載均衡——把 InsForge 的數據庫層替換成 Pigsty 管理的實例，等于給一輛跑車換了個專業底盤。

所以，InsForge 已經被納入了 Pigsty 全家桶。（當然，也是 Claude 干的，哈哈）下個版本會作為可選模塊一起發布。Pigsty 負責數據庫層的高可用與運維，InsForge 負責面向 AI Agent 的應用層接口。當然，你也可以選擇獨立自建 InsForge，或者只用它的 MCP Server 對接自己的 PG 實例。

本來老馮自己還想糊一個 Pigsty 里面的 Vibe 平臺，現在好，有現成的了，那我也很開心的劃掉了這一項 TODO。這也是老馮一貫的理念：PostgreSQL 是數據庫世界的 Linux，圍繞它的每一個優秀組件都值得被納入生態、組合使用。 Pigsty 不是要把所有東西都自己寫一遍，而是要讓所有基于 PG 的好東西都能用得上、管得住、跑得穩。

當然，如果你都已經準備用這種產品形態了，用云服務耍一耍也不錯。

數據庫老司機

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

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

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