Skip to content
Get a quote

Supabase RealtimeSupabase Realtime is subscribed, but no changes arrive

The channel says SUBSCRIBED, a row changes, and nothing reaches the app. No error. Supabase’s own troubleshooting guide lists the causes in order of how often each one is the problem. Here they are, with the fix for each, or hand it over at a fixed price.

Short answer

First check the table is in the supabase_realtime publication, since Realtime ignores tables that aren’t. Then check row-level security: Realtime applies it as the subscribing user, so on a table with RLS it only sends changes that user is allowed to see, and SUBSCRIBED doesn’t mean they can. If events arrive but old values are empty, that’s replica identity. Last, check the table name, schema and filter in the subscription.

The causes, most common first

  1. 01

    The table isn’t in the Realtime publication

    “Realtime doesn’t watch every table by default. Each one has to be added to a publication called supabase_realtime.” Supabase, Postgres Changes Troubleshooting

    Creating a table and turning on Realtime for it are two separate steps. Add the table to the supabase_realtime publication in Database, Publications in the dashboard, then try again.

  2. 02

    Row-level security hides the row

    “SUBSCRIBED only means the WebSocket connected. It says nothing about whether that client is allowed to see the data.” Supabase, Postgres Changes Troubleshooting

    Realtime enforces row-level security the way a normal query would, as the subscribing user (deletes are the exception). Sign in as that user and select the changed row; if nothing comes back, the policy is the cause. For updates, the policy generally has to allow both the old and the new version of the row, or the event can fail to deliver.

  3. 03

    Old values are empty

    “If events are arriving but payload.old is mostly empty or null, that’s a replica identity problem, not a delivery problem.” Supabase, Postgres Changes Troubleshooting

    If events arrive but the old record only has the id, Postgres is sending just the primary key. Setting the table’s replica identity to full sends the whole old row, but on a table with row-level security the old record still holds only the primary key, so don’t build logic on it there.

  4. 04

    The subscription code doesn’t match

    Check the table name and schema match exactly, the filter is written like room_id=eq.abc123, and the status callback is logged. In React and Next.js, clean up old channels when a component re-renders, or you’ll get duplicate or stale subscriptions.

Checked against the vendor’s docs on : Supabase: Realtime Postgres Changes troubleshooting; Supabase docs: Postgres Changes.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: New row violates row-level security · RLS is on: is the data safe now? · Free Supabase RLS policy checker

Questions

More on this error

Why do I get inserts and updates but no deletes?

Supabase says you can only filter delete events if the table’s replica identity is set to full, so a filtered subscription gets nothing for deletes until you set it. Row-level security policies also aren’t applied to deletes, because Postgres can’t check access to a row that’s gone, so don’t rely on them to hide delete events.

Should I just turn off RLS so events arrive?

No. That would let anyone read the table through your public key. Fix the policy so each user can select the rows they should see, and Realtime follows it.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.

Describe your problem All fixes