Supabase PostgreSQL 平台

Supabase 为每个项目提供一个完整、独立的 PostgreSQL 数据库，并在其周围集成平台服务：Auth、Storage、Realtime、自动生成的 REST 与 GraphQL API（PostgREST）、Edge Functions，以及 Supavisor 连接池。数据库是真实的 PostgreSQL——可以用任何客户端连接、使用普通扩展——但安全模型和日常运维由平台塑造。与其他方案的定位对比见云服务版图。

平台包含什么

• 每项目一个完整 PostgreSQL 实例，同时提供直连和池化连接串。
• 与数据库集成的 Auth：用户身份存放在 auth.users，JWT 声明可在 SQL 内读取。
• 自动生成的数据 API，把 schema 中的表直接暴露给浏览器和移动客户端。
• 基于 PostgreSQL 逻辑复制的 Realtime 推送。
• Storage 与 Edge Functions，处理文件和靠近数据库的服务端逻辑。

这种捆绑正是选择 Supabase 的理由：一个平台替代整个后端层。它同时也是需要接受的主要代价——采用 Auth、Storage、Realtime 和 API 越多，应用与 Supabase 特有 schema 和服务的耦合就越深。

RLS 是安全边界

由于浏览器客户端可以通过自动生成的 API 直接访问表，行级安全不是加固选项，而是安全模型本身：

ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users can read their own notes"
ON notes FOR SELECT
USING (user_id = auth.uid());

CREATE POLICY "users can insert their own notes"
ON notes FOR INSERT
WITH CHECK (user_id = auth.uid());

auth.uid() 从请求的 JWT 中读取用户 id，因此前端可以直接经 API 查询，由数据库强制所有权边界。三条规则保证这套模型不失效：

1. 对每张经 API 暴露的表启用 RLS，包括之后新增的表——schema 暴露什么，API 就暴露什么。
2. 用匿名和已认证两种角色测试策略，而不是只用控制台的 service 连接验证。
3. 永远不要向客户端下发 service_role key；它会完全绕过 RLS。

需要接受的差异

• 备份与 PITR 取决于套餐。 免费计划没有自动备份和 PITR——当前数字见免费 PostgreSQL 选型——付费档位的保留期和恢复粒度也不同。写入数据前，确认备份文档与你的 RPO 匹配。
• 连接预算由平台决定。 直连连接数有限；serverless 和高并发客户端走 Supavisor，其 transaction pooling 模式会限制 prepared statement 等会话级特性。用池化连接串测试你的驱动和 ORM，而不是只测直连。
• Realtime 消耗数据库资源。 它经逻辑复制流式推送变更，高写入频率的表和过大的 publication 会在同一个服务查询的实例上产生真实的 WAL 和复制负载。
• 退出时需要拆解平台组件。 pg_dump 能导出数据，但 Auth 用户、Storage 对象、Realtime 订阅和 Edge Functions 都是平台服务，dump 不会包含它们。

生产前验证

1. 每张经 API 暴露的表都已启用 RLS，并从匿名和已认证两种上下文完成策略测试。
2. 对照实际付费的套餐确认备份、PITR 和恢复粒度，并完成一次真实恢复演练。
3. 用池化连接串测试驱动、ORM 和迁移工具，包括 prepared statement 行为。
4. 按生产形态的写入频率压测 Realtime 负载。
5. 完成一次覆盖 pg_dump 加 Auth、Storage、函数处置方案的导出演练。

池化、监控和恢复演练等跨平台内容见生产环境技术栈。