Supabase Realtime 评测：用 Elixir 和 Phoenix 构建的 WebSocket 实时层
通过 WebSocket 进行广播、状态和 Postgres 更改。这是一个使用 Elixir 使用 Phoenix 框架构建的服务器，支持以下功能： 广播：以低延迟从客户端向客户端发送临时消息。
秒懂
- 它是什么？
- Supabase Realtime 是一个基于 Elixir 和 Phoenix 的服务器，通过 WebSocket 提供 Broadcast、Presence 和 Postgres Changes 三种能力。本文分析它的工作机制、部署方式、局限性和适用场景。
- 适合谁用？
- Supabase Realtime 适合已经使用 Supabase 生态、需要快速集成实时功能的团队，尤其是那些需要 Postgres 变更推送和 Presence 同步的场景。它不适合对消息投递有严格保证的应用，因为官方明确不保证每条消息都能送达。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Elixir（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁需要它
Supabase Realtime 解决的是 Web 应用中的实时数据同步问题。传统做法是前端轮询后端接口，延迟高且浪费资源。这个项目用 WebSocket 提供了一条长连接通道，让服务器主动推送数据。它面向的是使用 Supabase 平台的开发者，尤其是那些已经用 Postgres 作为数据库、需要实时功能的团队。你可以用它来实现聊天室、协作编辑、在线用户列表、数据库变更通知等功能。它不是一个通用消息中间件，而是紧密绑定在 Postgres 和 Phoenix 生态上的专用服务器。
三种核心机制：Broadcast、Presence 和 Postgres Changes
这个服务器提供三个独立的能力。Broadcast 是发送临时消息，比如一个用户在画布上移动光标，其他用户实时看到。消息是短暂的，不持久化。Presence 用于跟踪和同步客户端之间的共享状态，比如在线用户列表，当用户加入或离开时自动通知其他客户端。Postgres Changes 则是监听数据库的变化，通过 Postgres 的订阅机制获取 INSERT、UPDATE、DELETE 事件，然后推送给授权的客户端。这三种机制都通过 Phoenix Channels 实现，客户端使用 @supabase/realtime-js 库连接。值得注意的是，Postgres Changes 在 v1 中就有，而 Broadcast 和 Presence 是 v2 新增的。
消息投递的诚实说明：不保证送达
README 中直接写明：服务器不保证每条消息都会送达客户端。这是一个重要的设计取舍。对于 Broadcast 和 Presence 这类临时状态，丢失消息可能可以接受，因为下一秒会有新状态覆盖。但对于 Postgres Changes，如果一条数据库更新丢失，客户端可能永远不知道。这意味着你不能用它来实现需要严格一致性的功能，比如金融交易通知。如果你需要可靠投递，必须在应用层实现确认和重试机制，或者选择其他消息队列。这个限制是明确写在文档里的，不是隐藏的坑。
部署与配置：环境变量和 Docker
官方提供了 Docker 镜像，最新版本可以在 hub.docker.com/r/supabase/realtime 找到。本地开发可以参考 DEVELOPERS.md，其中提到使用 mise 管理任务。配置主要通过环境变量完成，具体列表在 ENVS.md 中。你需要设置数据库连接信息、端口、认证密钥等。ERROR_CODES.md 列出了操作错误码，OBSERVABILITY_METRICS.md 提供了监控指标。对于生产部署，你还需要配置 Postgres 的权限，特别是 supabase_admin 角色。不同版本的 Postgres 要求不同，15.x 16.x 17.x 需要 superuser 来运行迁移，但租户授权不需要 superuser。
Postgres 版本兼容性的实际约束
README 中有一张兼容性表格，列出了不同 Postgres 版本的支持状态。14.x 以下不支持，14.x 需要 superuser 设置 log_min_messages，而且 14.5 以下版本中，在触发器里通过 PERFORM 调用 realtime.broadcast_changes 是不支持的。15.x 在 15.14.1.018 之前缺少 supautils.policy_grants，需要手动处理。15.x 之后和 16.x、17.x 则需要 superuser 运行迁移，但租户授权不需要。这些细节意味着你不能随意选择 Postgres 版本，必须按照官方列表来。如果你使用的是托管 Postgres 服务，可能没有 superuser 权限，这会导致迁移失败。在部署前，务必核对你数据库的版本和权限。
与替代方案的对比：Phoenix Channels 与自建 WebSocket
一个直接的替代方案是使用原生的 Phoenix Channels，因为 Realtime 就是基于 Phoenix 构建的。如果你已经在使用 Elixir 和 Phoenix，你可以直接使用 Phoenix Channels 来实现类似功能，而不需要额外部署 Realtime 服务。这样你能获得更大的灵活性，比如自定义消息路由、认证逻辑和持久化策略。另一个替代方案是完全自建 WebSocket 服务器，用 Node.js 或 Go 等语言。这样做的好处是你可以完全控制协议和投递保证，但需要自己处理连接管理、心跳、消息广播等底层细节。Realtime 的优势在于它已经把这些都封装好了，并且与 Supabase 的客户端库无缝集成，缺点是它是一个黑盒，你无法轻易修改内部行为。
维护与升级成本，以及许可证
项目使用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。代码处于活跃开发中，README 提到代码库正在大量开发，文档不断演进。最近发布频率很高，v2.130.0 在 2026-08-26 发布，同一天还有两个补丁版本。这意味着你需要关注版本更新，因为 API 和配置可能变化。升级时需要测试 Broadcast、Presence 和 Postgres Changes 三个功能是否正常。由于是 Elixir 服务，运维团队需要熟悉 BEAM 虚拟机和 Phoenix 框架，这比管理普通 Web 服务更复杂。监控方面，OBSERVABILITY_METRICS.md 提供了指标，但你需要自己集成到监控系统。
编辑结论
Supabase Realtime 适合已经使用 Supabase 生态、需要快速集成实时功能的团队，尤其是那些需要 Postgres 变更推送和 Presence 同步的场景。它不适合对消息投递有严格保证的应用，因为官方明确不保证每条消息都能送达。也不适合需要自定义协议或非 Postgres 数据源的团队，因为它的核心绑定在 Postgres 和 Phoenix Channels 上。在采用之前，先确认你的 Postgres 版本在支持列表内，15.x 以下需要额外处理 superuser 权限问题。还要检查你的客户端库是否支持 v2 的 Broadcast 和 Presence，因为 v1 只有 Postgres Changes。最后，评估运维成本：这是一个 Elixir 服务，你需要掌握 BEAM 的部署和监控，而不是简单的 Node.js 或 Python 进程。
社区笔记