解决什么

现代 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 获取完整流程