Instead of polling, subscribe to a table. When a record is created, updated or deleted, you hear about it on the channel resource:<table>.

Turn it on in Studio

Two places do the same thing:
  • Data → open the table → Settings → Behaviour → switch Broadcast changes on (push row changes to realtime subscribers) and save.
  • Services → Realtime → Subscriptions → Database changes: the card lists your tables (resources) with a switch for each. Two ways something outside a channel finds out about an event: database-change broadcasting, and webhooks. If you have none yet it says No resources defined yet.
Also check the table’s Access tab: people receive changes only for rows their See the list / Open one record rule allows.

Listen

payload also carries resource and change.

Who hears what

You receive only changes to rows your read rule allows, checked against the row as it was and as it is now. Ada hears about her tasks, Bob about his, and neither learns the other’s exist. Columns marked Write only are removed from the message. Nobody can publish to resource: channels except the platform.

A complete live list

Load, then listen, then catch up after reconnects:
A Map keyed by id means a repeated message is harmless. replay fills in what happened while the connection was down.

Changes made outside the API

By default only writes through the API announce themselves. To include SQL, other services and migrations, switch on Capture changes made outside the API in the table’s Settings → Behaviour. See Events and realtime.

Watch it in Studio

In Realtime → Playground, join resource:tasks and make a change in the table editor: the message appears. In Overview, the broadcast counts rise.

Server-side reactions

Live records are for connected apps. To run work when a record changes (an email, a webhook), use events and subscriptions.

Table settings

Where Broadcast lives.

Playground

Watch a channel.