解決什麼

現代 AI 應用開發需要同時處理資料庫、使用者認證、檔案儲存、函式計算和 AI 模型呼叫等多個後端服務,傳統 BaaS 平臺(如 Supabase)缺乏對 AI 工作流的原生支援。Butterbase 提供一體化解決方案,特別增加了 AI 閘道器、RAG(檢索增強生成)和 MCP(模型上下文協議)伺服器,讓 AI 代理能夠通過標準化工具直接操作後端,無需編寫膠水程式碼。專案採用 Apache 2.0 協議完全開源,支援 Docker 自託管,避免供應商鎖定。

為何火

該專案在 3 周內獲得 1810 stars,核心吸引力在於三點:一是對標 Supabase 但強化 AI 能力,內建 AI 閘道器統一管理聊天/嵌入/模型列表,整合 RAG 文件檢索;二是首創將 MCP 協議整合到 BaaS 中,所有後端能力(資料庫操作、檔案上傳、函式呼叫)都暴露為 MCP 工具,Claude 等 AI 代理可直接呼叫;三是技術棧現代(TypeScript + Deno + Postgres),提供 Durable Objects 支援有狀態長連線場景(聊天室、多人協作)。官方還開源了 Claude Code 外掛,包含 30+ 引導式技能模板,從創意到部署全流程自動化。

核心功能

資料層:Postgres 資料庫支援宣告式 schema、自動生成 REST API、行級安全策略(RLS);新增 KV 鍵值儲存(帶 TTL 和審計);S3/R2 相容的物件儲存。

計算層:Deno 執行時執行 TypeScript 函式;Durable Objects 實現按鍵隔離的有狀態 Actor;WebSocket 即時訂閱表變更;支援 Next.js/Remix 邊緣 SSR 和靜態站點託管。

AI 層:統一 AI 閘道器接入多模型(需自行配置 API);託管 RAG 集合,自動文件切分和向量化;通過 Composio 整合第三方工具。

身份與運維:郵箱 + OAuth 多平臺登入(Google/GitHub/Apple 等);結構化審計日誌;Webhook 出站事件;多區域應用遷移指令碼。

代理介面:HTTP /mcp 端點或 stdio 方式(npx @butterbase/mcp)暴露所有能力為 MCP 工具,AI 可直接操作後端而非通過 SDK。

安裝

需要 Docker、Node.js 22+ 和 npm。克隆時必須包含子模組(Claude 外掛在獨立倉庫):

git clone --recurse-submodules https://github.com/butterbase-ai/butterbase.git
cd butterbase
npm ci
cp .env.example .env
docker compose -f docker-compose.local.yml up -d

首次啟動需構建映象(數分鐘),等待健康檢查通過後手動執行資料庫遷移(README 示例在第 4 步被截斷,需查閱完整文件)。本地開發預設使用 Redis 作為 KV 儲存,生產環境可替換為雲服務。

適合誰

AI 應用開發者:需要快速搭建聊天機器人、知識庫問答、AI 工作流的團隊,MCP 整合可讓 Claude 等代理直接呼叫後端
Supabase 使用者:尋求更強 AI 能力或需要完全自託管的專案,功能對等且增加 Durable Objects 和 AI 閘道器
全棧獨立開發者:一人團隊用 Docker Compose 即可獲得企業級後端能力,TypeScript 全棧降低學習成本
不適合:純前端開發者(需理解 Postgres RLS 和 Deno 執行時)、需要商業支援的企業(自託管版無 SLA 保障)

社群評價

暫無足量社群公開討論,以下為基於專案本身的中立評估:

專案在 GitHub 快速積累關注,Discord 社群已建立但討論熱度待觀察。技術亮點是 MCP 協議的實際落地應用,這在開源 BaaS 中屬首創,理論上可大幅簡化 AI Agent 與後端的整合複雜度。Durable Objects 的引入填補了 Supabase 在有狀態場景的空白。潛在風險是專案僅 3 周曆史,生產穩定性未經大規模驗證;自託管版的 AI 閘道器需自行對接模型 API,國內使用者需處理網路訪問和 API 金鑰管理。文件結構完整(包含 SETUP.md、ROADMAP.md),但部分章節(如遷移步驟)在 README 中被截斷,需查閱倉庫內完整文件。

選型對比

vs Supabase:Butterbase 功能對等(Postgres + Auth + Storage + Functions + Realtime),增加 Durable Objects、AI 閘道器、RAG 和 MCP 伺服器。Supabase 生態更成熟(客戶端庫豐富、商業支援完善),Butterbase 更適合 AI 原生場景且自託管無限制。兩者都基於 Postgres,遷移成本較低。

vs Firebase:Firebase 是 NoSQL(Firestore)且深度繫結 GCP,Butterbase 使用關係型資料庫且可部署到任意環境。Firebase 的即時資料庫更易用,Butterbase 的 RLS 和 SQL 查詢更靈活。

vs 自建:Butterbase 省去整合認證(Passport.js)、儲存(MinIO)、函式(自建 FaaS)的工作量,代價是需要理解其架構約定(如 RLS 策略語法、Deno 執行時限制)。

已知坑

子模組依賴:必須用 --recurse-submodules 克隆,否則 Claude 外掛缺失導致部分功能不可用,普通克隆後需手動 git submodule update --init
手動遷移:資料庫 schema 不自動應用,首次部署後需手動執行遷移命令(README 示例未完整展示)
AI 閘道器配置:自託管版不含上游路由介面卡,需自行實現 RouterAdapter 介面對接 OpenAI/Azure/國內大模型,國內使用者需處理 API 訪問和金鑰管理
多區域功能:應用跨區域遷移指令碼(scripts/move-app/)存在,但文件未詳細說明操作步驟和資料一致性保障
生產就緒度:專案建立僅 3 周,雖然維護活躍(今日仍有提交)但缺乏長期生產驗證,建議先在非關鍵專案試用
文件完整性:README 中安裝步驟第 4 步被截斷,需查閱 SETUP.md 獲取完整流程