Supabase
围绕 PostgreSQL 构建的开源后端开发平台。
项目概述
Supabase 将数据库、认证、存储、实时订阅和边缘函数组合成完整后端平台，同时保持 PostgreSQL 生态的开放性与可迁移性。
Supabase 以完整 PostgreSQL 数据库为核心，将身份认证、自动生成的数据 API、对象存储、实时消息和边缘函数组合为一套后端开发平台。开发者仍可使用 SQL、数据库连接、迁移和 Postgres 扩展，而客户端 SDK 则提供适合 Web、移动端和服务端的统一访问方式。它既提供托管服务，也公开核心组件供有基础设施能力的团队自托管。
主要特点
Supabase 围绕 PostgreSQL 提供从数据建模到用户访问和实时交互的一体化后端能力。
完整 PostgreSQL 数据库
每个项目获得可直接连接的 Postgres，支持关系、事务、视图、函数、触发器及 pgvector、PostGIS 等扩展。
自动生成数据 API
根据数据库 Schema 提供 REST 等访问接口，并通过 JavaScript、Flutter、Swift、Python 等 SDK 简化查询。
认证与行级授权
支持密码、Magic Link、OTP、社交登录和 SSO，并将 JWT 身份与 PostgreSQL Row Level Security 结合。
对象存储
提供文件 Bucket、细粒度访问策略、CDN、图片转换及可恢复上传，并通过 Postgres 元数据管理权限。
实时通信
Realtime 提供 Broadcast、Presence 和 Postgres Changes，可用于聊天、在线状态、通知及协作交互。
边缘函数
使用 TypeScript 编写靠近用户运行的服务端逻辑，适合 Webhook、第三方 API 集成和需要密钥的操作。
本地开发与迁移
CLI 可在 Docker 中启动本地技术栈，并通过 SQL Migration、Seed 和类型生成建立可复现的交付流程。
适用场景
适合希望快速交付产品，同时保留 SQL、关系模型和数据库可迁移性的团队。
SaaS 与多租户应用
Auth、关系模型和 RLS 可将组织、成员、订阅和业务数据组织在同一 PostgreSQL 权限体系中。
Web 与移动端 MVP
现成的认证、数据 API 和客户端 SDK 能减少后端样板代码，适合快速验证产品并持续演进。
实时协作产品
Broadcast、Presence 和数据库事件适合聊天、在线光标、通知、白板及多人工作空间。
内容与媒体应用
Postgres 管理结构化内容，Storage 保存头像、图片和文件，并通过访问策略控制公开与私有资源。
AI 搜索与 RAG
pgvector、全文检索、关系数据和 Edge Functions 可组合语义检索、混合搜索及嵌入生成流程。
内部工具与运营后台
SQL、自动 API、细粒度权限和管理界面适合快速构建数据录入、审批、报表与运营工具。
优点与注意事项
技术选型不仅要看能力，也要理解它带来的团队成本。
主要优点
Supabase 擅长的地方
- 以标准 PostgreSQL 为核心，数据模型、SQL 技能和迁移工具可复用
- 数据库、认证、存储、实时和函数在同一项目中协同工作
- RLS 可以把授权规则放到最接近数据的位置统一执行
- 客户端 SDK 和自动 API 缩短前端与移动应用的开发周期
- 支持本地技术栈、版本化迁移、Seed 和自动生成 TypeScript 类型
- 开源组件和数据库直连降低对专有数据接口的长期依赖
需要注意
采用前应考虑的问题
public 等暴露 Schema 中的表必须启用 RLS 并设计完整策略；遗漏或过宽策略可能直接暴露用户数据。
service_role 或 Secret Key 会绕过普通访问控制，绝不能放入浏览器、移动应用、日志或公开仓库。
复杂业务、跨表事务和敏感流程更适合放入数据库函数、Edge Functions 或独立服务端，而不是散落在客户端。
索引、查询计划、连接池、锁、迁移、备份和容量规划不会因为平台托管而消失，规模增长后必须持续治理。
高频协作更适合 Broadcast；直接订阅 Postgres Changes 在大量连接和复杂过滤下需要评估扩展性与配额。
自托管需要自行负责升级、监控、备份、安全、邮件、对象存储和多服务高可用，通常比单独维护 Postgres 更复杂。
快速开始
创建一张受 RLS 保护的待办事项表，并通过 TypeScript 客户端安全访问数据。
bashnpm install @supabase/supabase-jssqlcreate table public.todos (
id bigint generated by default as identity primary key,
user_id uuid not null references auth.users(id) on delete cascade,
title text not null,
completed boolean not null default false,
inserted_at timestamptz not null default now()
);
alter table public.todos enable row level security;
create policy "Users can read their own todos"
on public.todos for select
to authenticated
using ((select auth.uid()) = user_id);
create policy "Users can create their own todos"
on public.todos for insert
to authenticated
with check ((select auth.uid()) = user_id);
create policy "Users can update their own todos"
on public.todos for update
to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);typescriptimport { createClient } from "@supabase/supabase-js";
const supabase = createClient(
import.meta.env.VITE_SUPABASE_URL,
import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY,
);
const { data: todos, error } = await supabase
.from("todos")
.select("id, title, completed, inserted_at")
.order("inserted_at", { ascending: false });
if (error) throw error;
console.log(todos);typescriptconst {
data: { user },
} = await supabase.auth.getUser();
if (!user) {
throw new Error("请先登录");
}
const { data, error } = await supabase
.from("todos")
.insert({
user_id: user.id,
title: "学习 Supabase RLS",
})
.select()
.single();
if (error) throw error;
console.log(data);bashnpm install --save-dev supabase
npx supabase init
npx supabase start
npx supabase migration new create_todos
npx supabase db reset
npx supabase gen types --lang typescript --local > database.types.ts下一步：客户端只能使用 Publishable Key 或兼容的匿名公钥，并为暴露的表启用 RLS；Secret Key、service_role Key 和数据库连接字符串只能保存在可信服务端环境。
类似项目
这些平台同样提供数据库、认证、存储或实时能力，可用于快速构建应用后端。
Supabase vs Firebase
Supabase 和 Firebase 都能快速提供应用后端，但 Supabase 以关系型 PostgreSQL 和 SQL 生态为核心，Firebase 则以深度托管的移动与 Web 服务及文档数据库体验见长。
| 比较维度 | Supabase | Firebase |
|---|---|---|
| 核心数据库 | 完整 PostgreSQL 关系型数据库 | Cloud Firestore 文档数据库为主 |
| 查询与建模 | SQL、关系、Join、事务、函数和扩展 | 文档与集合模型，强调反规范化和客户端查询 |
| 访问控制 | Postgres Roles、Grants 与 RLS Policy | Firebase Security Rules |
| 实时能力 | Broadcast、Presence 和 Postgres 数据变化 | Firestore 实时监听与 Realtime Database |
| 服务端逻辑 | Postgres 函数、Edge Functions 或独立服务 | Cloud Functions、Cloud Run 及 Google Cloud 生态 |
| 离线体验 | 通常需要应用自行设计缓存与同步 | Firestore 客户端提供成熟的离线持久化能力 |
| 开放与迁移 | 可直连 Postgres，支持核心组件自托管 | 深度集成 Google 托管平台和专有数据接口 |
| 更适合 | 关系数据、复杂 SQL、可移植性和后端可控性 | 移动优先、离线同步和深度使用 Google Cloud 的产品 |
如果业务数据关系丰富、需要 SQL、数据库扩展或希望保留迁移与自托管路径，Supabase 通常更合适；如果产品以移动端为主、依赖成熟离线同步、Analytics、Crashlytics 和 Google Cloud 集成，Firebase 往往更省力。两者都应先验证权限模型、区域、成本和峰值负载。
资料核验
版本、维护信息与本页采用的官方资料来源。
本次核验覆盖 Supabase 的核心定位、主要能力、官方入口与开源许可。项目版本持续更新，具体补丁版本、兼容性和迁移要求请在采用前继续核对官方发布记录。
官方仓库未归档，核验时最近可见的代码活动日期为 2026 年 7 月 25 日。该状态表示项目近期仍有公开维护活动，不代表固定发布频率或长期支持承诺。