Supabase Realtime 项目中 PostgreSQL 权限配置问题解析

问题背景

在本地 Docker 环境中使用 Supabase Realtime 服务时，开发者遇到了一个典型的问题：当尝试通过 PostgreSQL 变更监听功能（postgres_changes）监控表数据变化时，系统报错"relation 'todos' does not exist"，导致变更事件无法正常广播到客户端。

问题现象分析

开发者按照官方文档配置了 todos 表，设置了匿名访问权限，并启用了 PostgreSQL 复制功能。然而在客户端订阅 schema 变更后，执行数据插入操作时，Realtime 服务容器日志中出现了表不存在的错误信息。

值得注意的是，当客户端未连接时，通过 Realtime 检查器可以观察到数据变更事件；而一旦客户端建立连接并订阅后，Realtime 服务就会进入异常状态，直到容器重启才能恢复正常。

深层原因探究

经过深入排查，发现问题根源在于数据库权限配置。具体表现为：

1. 项目初始配置中执行了 revoke all PRIVILEGES on database "postgres" from "anon" 命令，这导致匿名用户失去了数据库连接权限
2. Supabase Realtime 服务在运行时需要使用客户端提供的角色（本例中是 anon 角色）执行池化查询
3. 由于权限不足，Realtime 服务无法正常访问 todos 表，从而抛出表不存在的错误

解决方案

解决此问题的关键在于恢复匿名用户的基础连接权限。执行以下 SQL 命令即可修复：

GRANT CONNECT ON DATABASE "postgres" TO "anon";

这条命令明确授予了匿名用户连接数据库的权限，使得 Realtime 服务能够正常执行其功能。

最佳实践建议

1. 权限管理：在配置 Supabase 项目时，应确保至少保留匿名用户的基础连接权限
2. 错误排查：遇到类似"relation does not exist"错误时，应考虑检查数据库权限配置而非仅关注表结构
3. 环境验证：在本地开发和生产环境中保持一致的权限配置，避免因环境差异导致的问题
4. 监控机制：建立完善的日志监控系统，及时发现并解决权限相关问题

技术启示

这一案例揭示了分布式系统中权限管理的重要性。Supabase Realtime 作为中间层服务，其正常运行依赖于底层数据库的适当权限配置。开发者在进行安全加固时，需要全面考虑各组件间的依赖关系，避免因过度限制权限导致系统功能异常。

对于类似的技术栈，建议在项目初期就建立完整的权限矩阵文档，明确各角色所需的最小权限集，既能保障系统安全，又能确保功能完整性。