Supabase Realtime authorization: RLS decides who receives each event

Supabase Realtime authorization: no policy, no events

This is the silent one. The channel subscribes fine, the status says SUBSCRIBED, rows are changing, and the client receives nothing. The cause is almost always RLS: Realtime checks every event against the subscriber's policies, and without a matching SELECT policy the event is dropped for that subscriber.

Checkable procedure

1. Confirm the table is in the supabase_realtime publication: alter publication supabase_realtime add table your_table; or toggle it in the dashboard Publications settings. Not in the publication means no events for anyone.
2. Confirm the subscribing role has a SELECT policy on the table. An authenticated user needs to authenticated select; anon needs to anon. The policy's USING clause decides which rows' events reach them.
3. Remember that Realtime does not apply RLS to DELETE events the way you expect: Postgres cannot verify access to a deleted row, so design deletes accordingly (soft delete or broadcast the deletion explicitly).
4. For private channels that should only reach specific users, enforce it with policies, not with obscure channel names. Obscurity is not authorization.
5. For UPDATE and DELETE events where the client needs the old values, set alter table your_table replica identity full;. Without it, the old record is empty.

Quick test

Subscribe as the user, then change a row the user's policies allow and one they do not. Confirm events arrive only for the allowed row. If nothing arrives at all, check the publication first, then the SELECT policy.

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