Supabase realtime dashboard: live metrics with broadcast plus postgres_changes

TL;DR

Stream the aggregates instead. Decide what each widget actually needs: most need "the current value", not "every change". Reserve postgres_changes for widgets that genuinely need row-level detail, with tight filters per viewer (their team, their region). Handle reconnects: on resubscribe, refetch the current state via REST, then apply live events.

When to use

You are seeing this: A dashboard showing live data tempts agents into subscribing every viewer to the raw table. Use this skill when you run into "Supabase realtime dashboard: live metrics with broadcast plus postgres_changes".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Live dashboards: stream aggregates, not raw tables

A dashboard showing live data tempts agents into subscribing every viewer to the raw table. At scale that means every write is authorized and delivered to every viewer. Stream the aggregates instead.

Checkable procedure

1. Decide what each widget actually needs: most need "the current value", not "every change". A broadcast tick every few seconds with the computed metric beats per-row events.
2. Compute aggregates server-side (a materialized view refreshed on a schedule, or an Edge Function on demand) and broadcast the result. Viewers subscribe to the broadcast channel, which is cheap and needs no per-row authorization.
3. Reserve postgres_changes for widgets that genuinely need row-level detail, with tight filters per viewer (their team, their region). Filters keep the per-subscriber authorization cost proportional to what they see.
4. Handle reconnects: on resubscribe, refetch the current state via REST, then apply live events. Events missed during the gap otherwise leave the dashboard permanently stale.
5. Cap the viewer count per channel design: one channel per dashboard view, not per widget, to limit subscription overhead.

Ordering constraints

Aggregate computation before the broadcast. REST fallback before the live subscription code. If the fallback is wrong, the live view starts wrong and stays wrong.

Verification

Open the dashboard in two browsers, trigger underlying changes, and confirm both update within the tick interval. Kill the network briefly and confirm the view recovers to the correct current state on reconnect.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/realtime