Supabase

Supabase 是以 PostgreSQL 为核心的开源后端开发平台，提供托管云服务，也支持在自己的服务器或云环境中部署。每个项目使用完整的 Postgres 数据库，并在其上组合身份认证、自动生成的数据 API、对象存储、实时数据、Edge Functions 和向量能力。它适合希望快速搭建 Web、移动端或 AI 应用后端，同时保留 SQL、关系模型与一定迁移空间的开发者和团队。

各项服务都围绕 Postgres 工作

Supabase 并不是把多个互不相关的在线工具放在同一个控制台。Postgres 是项目的数据基础，Auth 负责用户身份与会话，Row Level Security（RLS）决定登录用户能读取或修改哪些行；Storage 的文件元数据和访问策略也可以与数据库权限配合。Realtime 监听数据库变化并向客户端广播，Edge Functions 则适合处理 Webhook、第三方 API、需要服务器密钥的逻辑和轻量服务端任务。

这种架构允许前端通过官方客户端库直接访问受策略保护的数据，但“可以从客户端调用”不代表默认安全。表结构、约束、索引和 RLS 策略仍需要像普通生产数据库一样设计。

建立第一个项目时的实用顺序

1. 创建项目并选择合适区域，保存数据库密码和项目标识，不要把管理凭据提交到代码仓库。
2. 先用 SQL Migration 或 SQL Editor 建立表、关系、约束和索引，再准备少量测试数据。
3. 为会被客户端访问的表启用 RLS，按匿名用户、登录用户和后台服务分别编写策略。
4. 接入 Auth 后验证注册、登录、会话刷新、退出和密码重置，再测试不同账号之间的数据隔离。
5. 按需增加 Storage、Realtime 或 Edge Functions，不要在需求尚未出现时同时开启所有能力。
6. 把数据库变更纳入迁移文件和版本控制，在测试环境验证后再部署到生产项目。

Dashboard 的 Table Editor 适合观察数据和快速验证，但长期项目不应只依赖手工点击修改数据库。使用迁移文件可以让团队知道某个字段、策略或函数何时改变，也便于建立预发布环境和回滚方案。

客户端密钥正在从 anon 迁移到 publishable

Supabase 正在用 sb_publishable_... 与 sb_secret_... 替代旧的 JWT 型 anon 和 service_role 密钥，官方文档给出的弃用节点是 2026 年底。新旧密钥可以并存迁移：浏览器、移动端和公开客户端代码改用 publishable key；服务器、Edge Functions 与后台任务改用 secret key。secret 与旧 service role 都会绕过 RLS，不能进入前端或代码仓库。把高权限密钥写进前端环境变量，即使变量名带有“private”，构建后仍可能被用户取得。

• 先写拒绝策略：新表默认不要假设客户端应该拥有全部读写权限。
• 按用户验证：至少用两个普通账号测试越权读取、更新和删除。
• 后台操作隔离：支付回调、管理员任务和批处理放在服务端执行，并检查调用者身份。
• 分阶段迁移：在 Dashboard 的 Settings → API Keys 创建新密钥，逐个替换客户端或后台组件，确认无旧依赖后再停用 legacy key。
• 记录密钥轮换：密钥泄露时要能定位使用位置、轮换并撤销旧凭据。

托管 Supabase 与自托管不是同一种维护成本

官方文档明确指出，自托管版本更接近单个项目，并不包含托管平台的全部能力；分支、高级指标、托管备份与时间点恢复等平台功能可能不可用或需要自行实现。因此，自托管的价值是控制权，而不是自动获得更低成本或更少维护。

什么时候 Supabase 比自建后端省力

它特别适合数据天然适合关系模型、团队熟悉 SQL，并且希望把认证、文件、实时订阅和 API 快速组合起来的产品。原型、内部工具、内容应用、会员系统、协作产品和带向量检索的 AI 应用都可以从统一的项目模型中受益。若业务需要非常特殊的数据库引擎、重型长任务、复杂消息系统或跨数据库事务，仍可能需要额外服务，而不是把所有逻辑塞进 Edge Functions。

“使用 Postgres”不等于迁移零成本

数据库表和标准 SQL 有助于降低锁定，但完整迁移还涉及 Auth 用户、对象存储、RLS 策略、数据库扩展、函数、实时订阅和客户端代码。选型时应提前测试数据导出、备份恢复和替代连接方式；生产环境还要观察连接池、查询计划、索引、日志与费用，而不是只看开发阶段是否容易上手。

Supabase 的套餐、区域和平台能力会变化，生产项目前应核对现行定价与控制台；密钥迁移、备份恢复和 RLS 测试都应在非生产环境先验收。