Broadcast from Database Replication Lag report
The Broadcast from Database Replication Lag report monitors the median time between when a message is committed to the database and when it is broadcast to Realtime clients. When using broadcast from database (by inserting messages into realtime.messages), Realtime reads changes from the Write-Ahead Log (WAL) using logical replication. The lag represents the time it takes for changes to be processed and broadcast to subscribed clients. Higher lag values indicate delays in the replication pipeline, impacting real-time responsiveness. Available for Pro, Team, and Enterprise plans.
Broadcast Events report
The Broadcast Events report monitors the volume of broadcast messages sent through Realtime channels over time. Broadcast events are low-latency messages sent between users using Realtime's pub/sub pattern, sent from client libraries, REST APIs, or directly from database. Each event represents a message broadcast to subscribers of a specific channel topic. Essential for understanding messaging patterns and identifying when approaching message throughput limits. Available for all plans.
Broadcast payload size limits by plan
Broadcast payload size limits vary by plan: Free plan has 256 KB maximum, Pro plan has 3,000 KB maximum, Pro no spend cap has 3,000 KB maximum, Team plan has 3,000 KB maximum, and Enterprise plan has 3,000 KB maximum.
Broadcast configuration options
Broadcast config in phx_join contains: `ack` (boolean, acknowledge broadcast messages), `self` (boolean, include the sender in broadcast messages), optional `replay` object with `since` (timestamp in milliseconds) and optional `limit` (number of messages), and optional `replication_ready` (boolean, when true the server emits a system event once Postgres replication connection is ready).
Broadcast message format (text frame)
Broadcast events sent as text frames contain: `event` (name of user event), `payload` (any JSON-serializable data), and `type` (must be 'broadcast'). Broadcast messages can be sent on both text and binary frames.
Broadcast binary frame format (type 0x04 - USER_BROADCAST)
USER_BROADCAST binary frame structure: Type (0x04, 1 byte), Topic Size (1 byte, max 255), User Event Size (1 byte, max 255), Metadata Size (1 byte, max 255), Payload Encoding (1 byte, 0=binary, 1=JSON), followed by variable-length fields: Topic, User Event, Metadata (JSON), User Payload.
Broadcast server message format (text frame)
Broadcast messages received from server contain: `event` (user event name), `meta` (metadata object with `id` as UUID and `replayed` as boolean, not always present), `payload` (any JSON-serializable data), and `type` ('broadcast').
Broadcast errors and ack behavior
Broadcast errors only affect private channels. When config.broadcast.ack is false (default), all push failures including size violations and RLS write denials are silently dropped. RLS denials are always silent regardless of ack setting. When ack is true, server replies with response.error (atom string, e.g., 'payload_size_exceeded'), not response.reason.
Broadcast text frame example in protocol 2.0.0
Example broadcast message in protocol 2.0.0: ['10', '1', 'realtime:chat-room', 'broadcast', { 'event': 'user-event', 'type': 'broadcast', 'payload': { 'content': 'Hello, World!', 'createdAt': '2025-11-17T21:14:14Z', 'id': '9b823349-71c0-465b-9a83-a63aa2a9ae6d', 'username': 'VCSHLD556nQD-B-vUTJJ3' } }]