•2025年09月
systems

Engineering Realtime Data Sync with Supabase Postgres Subscriptions, Edge Functions, and RLS

面向可扩展 web/mobile 应用，给出 Supabase Realtime Postgres 订阅的工程实现、RLS 安全集成和 Edge Functions 处理的实用参数与最佳实践。

在现代 web 和移动应用中，实时数据同步是提升用户体验的核心需求，尤其是在协作工具、聊天应用或仪表盘场景下。Supabase 作为开源的 Postgres 开发平台，通过其 Realtime 功能实现了高效的数据库变更订阅机制。这种机制利用 Postgres 的内置复制功能，将 INSERT、UPDATE 和 DELETE 等事件通过 WebSockets 广播给授权客户端，避免了轮询带来的延迟和资源浪费。工程实践中，结合行级安全（RLS）和 Edge Functions，可以构建出安全、可扩展的实时系统。本文将从订阅设置、安全集成、函数处理到性能优化，提供可落地的工程参数和清单，帮助开发者快速实现。

Realtime Postgres 订阅的核心工程实现

Supabase Realtime 的 Postgres Changes 功能是实时同步的基础。它基于 Elixir 服务器监听 Postgres 的复制槽（replication slot），将数据库变更转换为 JSON 格式后通过 WebSockets 分发。订阅时，需要在仪表盘中启用 supabase_realtime 发布（publication），并为目标表添加复制：ALTER PUBLICATION supabase_realtime ADD TABLE your_table;。客户端使用 Supabase JS 库订阅，例如：

const channel = supabase.channel('db-changes') .on('postgres_changes', { event: '*', schema: 'public', table: 'todos' }, payload => { console.log('Change received!', payload); }) .subscribe();

这种订阅支持事件过滤，如 event: 'INSERT' 只监听插入操作，或 filter: 'id=eq.1' 针对特定行。证据显示，这种机制在低负载下延迟可控制在 100ms 以内，但高并发时需注意单线程处理限制：每个变更事件需逐一检查 RLS 权限，导致吞吐量上限约为 64 changes/sec（基于 Supabase 基准测试）。

可落地参数：

  • 订阅 schema：优先使用 'public'，私有 schema 需授予 SELECT 权限给 authenticated 角色：GRANT SELECT ON non_private_schema.some_table TO authenticated;
  • 过滤器选择：使用 eq/ne/gt 等操作符，in 操作符最多支持 100 值；Delete 事件不可过滤，避免依赖其精确性。
  • 连接管理：客户端重连阈值设为 5s，超时 30s；使用 replica identity full 获取旧值：ALTER TABLE messages REPLICA IDENTITY FULL;

工程清单：

  1. 创建表并启用 RLS：CREATE TABLE todos (id SERIAL PRIMARY KEY, task TEXT); ALTER TABLE todos ENABLE ROW LEVEL SECURITY;
  2. 添加匿名/认证访问策略：CREATE POLICY "Allow public read" ON todos FOR SELECT TO anon USING (true);
  3. 启用复制并订阅：仪表盘 Publications 中 toggle 表，客户端 on('postgres_changes') 监听。
  4. 测试插入数据：INSERT INTO todos (task) VALUES ('Test'); 验证 WebSocket 推送。

集成行级安全（RLS）确保数据访问控制

RLS 是 Postgres 的原生特性，在 Supabase 中与 Auth 无缝集成，提供细粒度授权。启用 RLS 后，未授权查询将返回空结果，防止越权访问。例如，对于用户私有数据表 profiles，策略可限制为仅可见自身记录：CREATE POLICY "Own profile view" ON profiles FOR SELECT TO authenticated USING ((SELECT auth.uid()) = user_id);

更新操作结合 using 和 with check：CREATE POLICY "Update own profile" ON profiles FOR UPDATE TO authenticated USING ((SELECT auth.uid()) = user_id) WITH CHECK ((SELECT auth.uid()) = user_id); 这确保更新前检查所有权，更新后验证不变。Supabase Auth 的 JWT 辅助函数如 auth.jwt() 可进一步扩展，例如检查 app_metadata 中的团队 ID：USING (team_id IN (SELECT auth.jwt() -> 'app_metadata' -> 'teams'))。

性能证据表明，未优化 RLS 可导致查询时间从 10ms 飙升至 170ms，尤其在全表扫描时。优化后，通过索引和函数包装，改进率达 99%。引用 Supabase 文档：“Policies are SQL logic that you attach to a Postgres table, executed every time a table is accessed.”

可落地参数：

  • 角色指定：始终使用 TO authenticated/anon，避免 anon 执行昂贵策略。
  • MFA 强制：对于敏感更新，检查 aal: USING ((SELECT auth.jwt()->>'aal') = 'aal2');
  • 视图安全：Postgres 15+ 使用 WITH (security_invoker = true) 使视图遵守 RLS。

工程清单：

  1. 索引关键列：CREATE INDEX idx_user_id ON profiles (user_id); 针对策略中使用的字段。
  2. 函数包装：USING ((SELECT auth.uid()) = user_id) 而非 auth.uid() = user_id，缓存结果。
  3. 客户端过滤：查询时添加 .eq('user_id', userId)，辅助 RLS 优化计划。
  4. 测试策略：使用 service_key 绕过 RLS 模拟 admin，验证 anon/auth 行为。

使用 Edge Functions 处理实时事件和扩展逻辑

Edge Functions 是 Supabase 的分布式 TypeScript 运行时，部署在全球边缘节点，低延迟执行服务器逻辑。结合 Realtime，可在函数中订阅变化并触发下游动作，如发送通知或聚合数据。示例：在函数中初始化 Supabase 客户端，监听变化：

Deno.serve(async (req) => { const supabase = createClient(Deno.env.get('SUPABASE_URL'), Deno.env.get('SUPABASE_SERVICE_KEY')); const channel = supabase.channel('edge-changes').on('postgres_changes', { event: 'INSERT', table: 'messages' }, payload => { // 处理逻辑，如调用外部 API }).subscribe(); return new Response('Listening'); });

函数支持集成 Postgres 连接池（pg 库）和 Storage，适合 webhook 处理或 AI 推理。证据显示，Edge Functions 的冷启动 < 100ms，适合短时任务；长任务移至 background workers。

可落地参数：

  • 环境变量：使用 supabase secrets set API_KEY=xxx 存储凭证。
  • 并发限制：单函数 1000ms 执行上限，内存 256MB；区域调用指定 region: 'us-east-1'。
  • 日志监控：集成 Sentry，捕获错误：console.error('Error', e);

工程清单：

  1. CLI 部署：supabase functions deploy my-function --no-verify-jwt;
  2. 集成 Auth：验证 JWT：const { data: { user } } = await supabase.auth.getUser();
  3. 实时触发：函数中订阅变化，处理后广播：supabase.channel('broadcast').send({ type: 'update', payload });
  4. 测试本地：supabase functions serve，curl http://localhost:54321/functions/v1/my-function。

扩展性和监控要点

对于可扩展 web/mobile 应用，实时系统需考虑负载均衡。Realtime 的瓶颈在于 RLS 检查：100 用户订阅单表插入，将触发 100 次读操作。建议使用无 RLS 的公共表 + 客户端过滤，或服务器端 Realtime 广播重流。监控指标包括 p95 延迟（目标 < 250ms）、消息吞吐（max 32k/sec）和连接数（WebSocket 限 10k/项目）。

风险缓解：表名避免空格；Delete 无过滤时，使用软删除。回滚策略：若订阅延迟 > 1s，fallback 到轮询。

工程清单：

  1. 性能基准：模拟 100 changes/sec，监控 DB CPU > 80% 时升级 compute。
  2. 安全审计：定期审视 policies，避免宽松 using (true)。
  3. 扩展路径：>10k 用户时，引入 Kafka 或专用队列分担 Realtime。
  4. 部署 CI：GitHub Actions 自动 deploy functions 和迁移 RLS。

通过以上工程实践，Supabase 的 Realtime Postgres 订阅结合 RLS 和 Edge Functions，可构建出高效、安全的实时数据同步系统。开发者应从小规模原型起步，迭代优化参数，确保在生产环境中稳定运行。（约 1250 字）