Supabase：开源 Firebase

为什么需要 Supabase：从自建后端到即取即用的 BaaS

传统后端开发中，一个典型的数据驱动应用需要你单独搭建 API 服务、设计鉴权逻辑并维护数据同步。技术选型可能涉及 Express（Node.js 的轻量 Web 框架）、Django（Python 的 Web 框架）以及独立的实时推送组件 Redis Pub/Sub 或 WebSocket 服务，不仅代码量大，还需要持续关注模块间如何安全打通。多个服务之间既要保证低延迟又要确保数据一致性，在生产环境还要处理横向扩容和连接池调优，开发周期往往被「基建」而不是「业务」拖长。

Supabase 用一个统一平台替代了上述多个组件的集合：PostgreSQL 数据库直接暴露为 REST API 和实时订阅通道，官方客户端（JavaScript / Dart / Python 等）封装了认证、查询与文件上传。你可以先写 SQL 再让 PostgREST（自动将 SQL 表转换为 RESTful API 的工具）生成接口，也可以跳过 SQL 直接在界面建表、绑定权限策略 RLS（Row Level Security，PostgreSQL 中可以按行控制访问权限的机制）。AI 工程师不用关心请求路由和登录态管理，而是直接围绕向量数据、嵌入（Embedding）函数和用户表建模。

与 Firebase 相比，Supabase 的差异在于它开放与数据独立性：你拥有完整的数据库连接串，可以用任何 PostgreSQL 生态工具；还支持自定义 Docker 镜像自托管，规避了供应商锁定风险。而从身份认证到数据存储，Supabase 又比自建方案提供了更平滑的一体化体验。本质上它把「后端发布」压缩为「建表 + 配策略」，为 AI 应用的 MVVM MVP 原型快速验证铺平了道路。

安装与环境配置：3 步就绪

Supabase 的使用分两条路径：云端计划（直接在 supabase.com 创建项目）与本地开发（通过 CLI 在 Docker 中运行，生产可选自托管）。这里推荐本地先行，避免多项目互相干扰。

步骤一：安装 Supabase CLI

需先安装 Docker（桌面版或引擎均可），然后通过 Homebrew 安装 CLI：

步骤二：登录并初始化项目

在你的应用目录中运行以下命令，它会创建 supabase/ 配置目录，并生成 config.toml 与本地迁移文件：

supabase start 会基于 Docker 启动本地栈（Studio 控制台、Auth、PostgREST、Realtime、Storage），首次运行需拉取镜像。启动成功后，输出日志中会显示本地 API URL http://localhost:54321 与默认 anon 公钥。在浏览器打开控制台，可执行 SQL、浏览表结构和观看 API 文档。

步骤三：验证环境并创建首个表

通过 supabase status 查看服务列表与密钥，并在 SQL Editor 中运行建表语句：

# macOS 安装brew install supabase/tap/supabase # 其他平台（基于 npm）npm install -g supabase

supabase loginsupabase initsupabase start

create table books (  id bigint generated always as identity primary key,  title text not null,  author text,  created_at timestamptz default now());

快速上手：15 分钟创建数据表并调用 API

思路：用 PostgREST 把上一步创建的 books 表自动暴露为 Web API。你要做的只是配置好匿名权限，然后客户端就能直接查询。这里以 JavaScript（Vite 项目）为例：

1. 在项目目录安装 @supabase/supabase-js：npm i @supabase/supabase-js

2. 创建 .env 文件，填入从 supabase status 获取的 URL 与 anon key（示例中 http://localhost:54321）

3. 在 main.js 中初始化客户端并查询：

• const supabase = createClient(SUPABASE_URL, SUPABASE_KEY)

• 执行 const { data, error } = await supabase.from('books').select('*')

4. 插入一条测试数据：await supabase.from('books').insert({ title: 'RAG 实战', author: '张三' })

运行后你会看到插入与查询结果。进阶技巧：表结构变动后，在 Supabase Studio 中启用 Realtime 发布就能实时监听变更，前端自动订阅 channel 即可。后续接入 AI 的步骤是：借助 pgvector 扩展建立 embeddings 列，用 supabase-js 的 rpc() 方法调用数据库函数完成向量搜索。

// 可直接运行的 Node 或 Vite 内代码import { createClient } from '@supabase/supabase-js' const supabase = createClient(  'http://localhost:54321',  process.env.SUPABASE_KEY) async function main() {  const { data, error } = await supabase    .from('books')    .insert({ title: 'AI Engineering', author: 'Chip Huyen' })    .select()   if (error) throw error  console.log('插入成功:', data)  const { data: list } = await supabase.from('books').select('*')  console.log('当前表数据:', list)} main()

核心能力详解：4 大支柱

支柱一：PostgreSQL 数据库与 PostgREST API。 Supabase 的第一个支柱是数据库。所有表在「表编辑器」中创建或直接通过 SQL 创建，PostgREST 会同步为每张表生成标准 REST 端点（集合与单条记录）。查询支持过滤、排序、分页和嵌套资源，客户端无需编写后端路由。同时，你拥有原生 PostgreSQL 连接串，也可以使用 psql 等专业工具进行复杂查询，这让数据分析与报表开发毫无隔阂。

支柱二：Authentication 身份认证。 Supabase Auth 支持常见登录方式（邮箱/密码、OTP、OAuth 第三方）。它直接依赖数据库表 auth.users，并内置了行级安全策略生成器——你在控制台配置 RLS 策略，API 层就会自动校验登录态。对 AI 应用，这解决了用户数据隔离的关键问题：不同用户只能访问自己的知识库、会话记录，无需编写中间件。

支柱三：Realtime 实时订阅。 Realtime 基于 PostgreSQL 逻辑复制或 WebSocket 实现，支持行级变更（INSERT / UPDATE / DELETE）广播，也支持 Presence 自定义事件（用于在线状态检测与协同）。在这之上演进出的 Broadcast 功能可让客户端直接互发消息而不落库。RAG 场景里它常用于待处理文档的状态刷新，或让前端在后台任务完成时收到通知。

支柱四：Edge Functions 与 Storage。 Edge Functions 基于 Deno，实现边缘 JavaScript/TypeScript 函数的托管执行，延迟低且免运维；Storage 提供对象存储（图片、视频、PDF），与 RLS 策略集成，允许开发者按数据表级别控制文件读取权限。两者与 Supabase 的数据库、Auth 组合，足够支撑一个轻量级 AI 中间层——如代理 LLM 调用、保存中间结果或对上传文档做预解析。

生产部署与监控：从上线到运维

方式一：使用 Supabase 云平台。 在 supabase.com 创建项目后，你需要把 anon key 换成 service_role key 移到服务端调用，将项目从免费区升级为 Pro 计划以获得每日备份、7 天日志保留与多区域选择。云平台的横向扩容由官方负责，你只需要关注连接池大小与数据库负载。生产环境建议开启「连接池」（pgBouncer，一种为 PostgreSQL 提供连接池与复用的中间件），并把 Supavisor 作为连接代理，防止计算实例耗尽连接数。

方式二：自托管（Docker / Kubernetes）。 使用 Supabase CLI 可以在自己的 VPS 上启动整套服务，或用官方 Helm Chart（Kubernetes 应用打包格式）部署到 K8s。自托管让你保留完整数据和网络控制权，但你需要自行处理 PostgreSQL 备份、日志收集（Prometheus + Grafana）、自动扩缩容与安全补丁升级。这也适合对数据合规有强要求的内部 AI 平台。注意自托管不是简单跑一个容器，监控 Cassandra（Realtime）与 Postgres 的状态是常被低估的工作量。

可观测性。 云平台提供内置的 API 监控仪表盘，展示请求速率、错误率与延迟。「查询性能」页显示慢查询记录，日志浏览器可以按级别搜索和过滤。自托管方案一般用 exporter（如 postgres_exporter）结合 Prometheus 抓取指标。Supabase 也支持你接入 OpenTelemetry（一种可观测性标准框架），把尾部迁移追踪（如 Edge Function 的执行链路）下发到外部 APM（应用性能监控平台）。底线是至少做到连接池水位、数据增长速度、备份成功三个指标的周度巡检。

<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>把 anon key 当读写密钥用：anon key 默认受 RLS 限制，若要绕过 RLS 必须使用 service_role key，但后者不可暴露在前端，否则等于公开数据库权限——请将 service_role key 严格放入服务端环境变量。</li><li>建表后忘记启用 RLS：默认所有表都禁用行级安全，意味着任何人用 anon key 都能全表访问。每次新建表后应在 SQL Editor 执行 alter table ... enable row level security 并编写策略。</li><li>本地与云端的迁移不同步：长期使用在线 SQL Editor 建表再复制到本地迁移文件，容易造成回滚冲突。应引入 supabase db diff 自动生成迁移，保持 schema 以文件为唯一真相。</li><li>Realtime 表未开启复制：如果开启流式订阅后数据库变更不推送，往往是因为没有在「Publication」中把目标表加进复制集。</li><li>连接池使用量打满后服务不可用：免费版对连接数有限，生产请通过 Supavisor 连接，或配置客户端「连接池大小」并对长时间事务做超时限制。</li></ul>

版本迭代

Supabase 自 2020 年公开预览后持续迭代：v1.0 在 2024 年 4 月推出，标志着平台 API 稳定并进入生产可用；v2.0 于 2025 年 2 月发布，围绕多区域部署、连接池重构（Supavisor）与更细粒度安全控制展开。整体演进方向是「核心服务模块化、边缘能力增强、降低自托管门槛」。

AI 应用场景

常见误区

面试题

参考来源

• webpageSupabase 官网产品入口、定价与云控制台