Realtime Egress FAQ

实时出口作为你项目的统一出口使用的一部分进行计费。本常见问题解答会讲解哪些会被计入，哪些不会，以及如何调查两者之间的差异。

🌐 Realtime Egress is billed as part of your project's unified egress usage. This FAQ walks through what's counted, what isn't, and how to investigate a gap between the two.

实时出口指标具体包括什么内容？ #

🌐 What exactly is included in the Realtime Egress metric?

实时外发衡量从实时服务器发送到已连接客户端的数据，通过开放的 WebSocket 连接，以及对 HTTP 广播端点 发起的任何请求。这包括广播消息、Postgres 变更负载、Presence 事件，以及通过同一 socket 发送的 Phoenix 协议帧（见下文）。

🌐 Realtime Egress measures data sent from the Realtime server to a connected client over an open WebSocket connection, plus any request made to the HTTP Broadcast endpoint. This includes Broadcast messages, Postgres Changes payloads, Presence events, and Phoenix protocol frames sent over the same socket (see below).

它不包括实时服务器与你的 Postgres 数据库之间的内部流量（逻辑复制、用于从数据库广播的 pgoutput 读取，或复制槽管理）。这些流量从不会到达客户端，也不计入这个指标。

🌐 It does not include internal traffic between the Realtime server and your Postgres database (logical replication, pgoutput reads for Broadcast from Database, or replication slot management). That traffic never reaches a client and isn't part of this metric.

它只包括传输给已连接客户端的字节，还是也包括内部数据库到实时复制的流量？ #

🌐 Does it include only bytes delivered to connected clients, or also internal DB → Realtime replication traffic?

只有服务器发送到 WebSocket 的数据以及任何 HTTP 广播请求。数据库 → 实时逻辑复制流量（Realtime 内部用来读取数据库或 Postgres 变更以进行广播的连接）不计算在内——它从不离开 Realtime 服务到达客户端，所以不算作出站流量。

🌐 Only data the server sends to the WebSocket, and any HTTP Broadcast request. DB → Realtime logical replication traffic (the connection Realtime uses internally to read changes for Broadcast from Database or Postgres Changes) is not counted — it never leaves the Realtime service to reach a client, so it isn't part of Egress.

它包括复制槽初始化/重建还是数据库冷启动流量的广播？ #

🌐 Does it include replication slot initialization/recreation or Broadcast from database cold-start traffic?

不行。复制槽的创建、检查以及对你的数据库的重连尝试都是 Realtime 服务和 Postgres 内部的操作。即使你的租户经常处于空闲状态然后重新启动（比如日志显示 Stop tenant ... because of no connected users 然后槽被重新创建），这些活动也不会反映在你账单上的 Realtime 出站流量中。

🌐 No. Replication slot creation, checks, and reconnection attempts to your database are internal to the Realtime service and Postgres. Even if your tenant is frequently idling out and starting back up (for example, logs showing Stop tenant ... because of no connected users followed by slot recreation), that activity is not what's reflected in your billed Realtime Egress.

它包括 Phoenix/WebSocket 协议的开销吗（握手、心跳、phx_join、phx_leave、重连帧）？ #

🌐 Does it include Phoenix/WebSocket protocol overhead (handshake, heartbeat, phx_join, phx_leave, rejoin frames)?

是的——服务器通过开放的套接字发送的任何消息都算在内，包括心跳和 Phoenix 控制帧（phx_reply、phx_close、重新加入的负载）。实际上，这些开销和实际应用数据相比是很小的，除非客户端卡在加入/离开循环中（例如，一个出错的重连处理器不断地订阅和取消订阅同一个通道）。Realtime 会内部跟踪加入速率，所以如果你的数值相对于连接数来说异常高的话，值得排查一下是否存在失控的重新加入循环。

🌐 Yes — any message the server sends over an open socket counts, including heartbeats and Phoenix control frames (phx_reply, phx_close, rejoin payloads). In practice this overhead is minimal compared to actual application data, unless a client is stuck in a join/leave loop (for example, a broken reconnect handler that repeatedly subscribes and unsubscribes from the same channel). Realtime tracks join rate internally, so a runaway rejoin loop is something worth ruling out if your numbers look unusually high relative to your connection count.

即使负载很小，重复的租户启动/停止或冷启动循环会导致大量出站计费吗？ #

🌐 Can repeated tenant stop/start or cold-start cycles cause large billed egress even when payload is small?

不。租户在空闲（no connected users）后在下一次连接时重新启动，这是多租户架构的正常部分，并不是会增加实时出站流量的机制。如果你发现应用测量的有效负载和计费出站流量之间有很大差距，先看看消息量和分发情况（见下文），而不是租户生命周期事件。

🌐 No. Tenant idling out (no connected users) and starting back up on the next connection is a normal part of the multi-tenant architecture and is not a mechanism that inflates Realtime Egress. If you're seeing a large gap between your application-measured payload and your billed egress, look at message volume and fan-out first (see below) rather than tenant lifecycle events.

仪表板上的图表是分批显示的，还是用某种方式标记的，可能会让某一天看起来比实际使用量高很多？ #

🌐 Is the dashboard graph batched or attributed in a way that could make one day look much higher than actual usage?

没有已知的问题会导致这种情况。每日的实时流出量数字反映了当天的实际使用情况，而不是图表渲染或汇总方式造成的假象。

🌐 No known issue causes this. The daily Realtime Egress figure reflects real usage attributed to that day, not an artifact of how the graph is rendered or rolled up.

实时出站流量是否可以按来源或类型（广播 / Postgres 变更 / 在线状态 / 协议开销）进行分类？ #

🌐 Is a breakdown of Realtime Egress available by source or type (Broadcast / Postgres Changes / Presence / protocol overhead)?

目前没有。实时流出量只作为一个总数报告——仪表板或使用情况 API 今天都没有提供按来源或事件类型的细分数据。

🌐 Not currently. Realtime Egress is reported as a single aggregate number — there's no per-source or per-event-type breakdown available in the dashboard or usage APIs today.

测量的消息负载很小——为什么计费的实时输出量会高这么多？ #

🌐 Measured message payload is tiny — why is billed Realtime Egress so much higher?

这是最常见的混淆来源，几乎总是因为计算写入次数而不是计算已传递事件。在假设计费有问题之前，有几件事需要检查一下：

🌐 This is the most common source of confusion, and almost always comes down to counting writes instead of counting delivered events. A few things to check before assuming a billing issue:

1. 投递的事件 ≠ 数据库写入。 如果你使用 Postgres Changes 或 Database Broadcast，插入/更新的行数并不等于通过网络发送的事件数量。每一次插入/更新/删除都可能会向每个订阅的客户端发送一次投递，而不是只发送一个事件。
2. 按同时订阅者计算。 如果有20个客户订阅了同一个通道，一次数据库变更可能会产生20次独立的推送。估算实际外发量时，要用每次变更的负载大小乘以峰值同时连接数，而不是只看原始写入速率。
3. 每个通道的多重订阅会进一步加剧这一问题。 如果一个通道用多个过滤器订阅同一个表（例如，分别订阅 INSERT、UPDATE 和 DELETE，或者多个重叠的 postgres_changes 过滤器），同一条底层行的变化可能会被多次发送给同一个客户端。
4. Postgres Changes 的负载通常比你预期的要大。 与手工制作的 Broadcast 负载不同，Postgres Changes 事件包含整行数据（或者在 REPLICA IDENTITY FULL 下包含完整的旧行 + 新行），即使是很小的逻辑变动也可能达到几千字节——尤其是对于宽表或经过 TOAST 压缩的列。你可以通过过滤要发送的变动来避免传递无关的行，也可以通过选择特定的列来减小行的负载。

在放大测量的有效负载与计费出口之间的差距之前，重新使用已传递事件而不是写入来重新推导你的估算：(events per day) × (average delivered payload size) × (average concurrent subscribers)。这个计算通常可以解释最初看起来无法理解的差距。实时可观测性报告在这方面很有帮助——它显示了你的项目中连接的客户端数量、有效负载大小以及加入速率。

🌐 Before escalating a gap between measured payload and billed egress, re-derive your estimate using delivered events, not writes: (events per day) × (average delivered payload size) × (average concurrent subscribers). This calculation frequently accounts for a gap that initially looks inexplicable. The Realtime observability report can help here — it shows number of connected clients, payload size, and rate of joins for your project.

在联系 Supabase 支持关于 Realtime Egress 差异之前，应该检查些什么？ #

🌐 What should be checked before contacting Supabase support about a Realtime Egress discrepancy?

• 使用实际发送的事件和分发量重新计算你的预期流出（见上文），而不是用原始的数据库写入次数。
• 检查一下是否有通道有多个重叠的 postgres_changes 订阅，这可能会导致重复发送。
• 查看所述期间的峰值并发连接——并发量的小幅增加可能会大幅增加 Broadcast/Postgres 变更的外发量。
• 排除客户端重新连接循环（快速的 phx_join/phx_leave 循环）作为过多协议开销的来源。
• 如果你重新计算的估算值仍然跟账单上的数字差得很远，联系支持，提供你的项目编号、相关时间段以及你计算出的已交付事件数量，以便团队进一步调查。

相关指南 #

🌐 Related guides

• 了解你的使用情况
• Egress 常见问题
• 实时直播
• 实时 Postgres 变更