Supabase realtime dashboard: live metrics with broadcast plus postgres_changes

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