Title: Realtime updates not received on first page load when using createBrowserClient from @supabase/ssr in Next.js

[Ghoral24]

I’m experiencing an issue where realtime updates are not received on the first page load when using createBrowserClient (e.g. from @supabase/ssr or @supabase/auth-helpers-nextjs) in Next.js.

The connection appears to be established (channel subscribes without error), but no events are delivered until I navigate away and return (for example, visiting a detail page and then going back).

Reproduction Steps

1. Use createBrowserClient in a global provider or page component.
2. Subscribe to postgres_changes for a table via:
   supabase .channel('my-channel') .on( 'postgres_changes', { event: '*', schema: 'public', table: 'my_table' }, (payload) => console.log(payload) ) .subscribe();
3. Load the page — no realtime updates are received when the database changes.
4. Navigate to another page (e.g. /detail/[id]) and then return to the original page.
5. Updates begin to arrive as expected.

Expected Behavior
Realtime updates should start arriving immediately upon subscription on the first page load

Environment

1. @supabase/ssr: ^0.6.1
2. @supabase/supabase-js: ^2.54.0
3. next: ^15.3.2
4. Client creation method: createBrowserClient from @supabase/ssr
5. Setup: Supabase Realtime is enabled on the table in the dashboard.

[asrouji]

Same issue here! Also using @supabase/ssr in Next.js. Channel appears to subscribe without error on the first page load, but no updates are received on database changes. Once I navigate away and return, it works fine. If I hard reload on the realtime page, it breaks again until I repeat the navigation steps.

Using @supabase/ssr ^0.6.1, @supabase/supabase-js ^2.55.0, and next ^15.4.6

Interestingly I have no issues in my local environment with local Supabase (works on initial load) but it does not work on my Vercel deployment connected to my Supabase cloud project. Local and remote have identical schema and settings. Will have to investigate further.

@Ghoral24 any chance you've found a workaround to this issue?

[asrouji]

Found a hacky temporary fix: creating a "double connection". Basically create a dummy subscription first, then after a moment create the real one:

// First connection - seems to "prime" the system
const dummyChannel = supabase.channel(`dummy_${table}`)
  .on('postgres_changes', { event: '*', schema: 'public', table }, () => {})
  .subscribe()

// Real connection after delay
setTimeout(() => {
  const realChannel = supabase.channel(`realtime_${table}`)
    .on('postgres_changes', { event: '*', schema: 'public', table }, onUpdate)
    .subscribe()
  
  // Clean up dummy channel after real one is established
  setTimeout(() => supabase.removeChannel(dummyChannel), 1000)
}, 500)

The first subscription seems to prime the realtime connection somehow, then the second one actually receives events. I'm guessing this does the same thing as the "navigate away and return" that also worked.

Obviously this is not an ideal solution, unsure why the first connection succeeds but no messages are delivered.

[Ghoral24]

@asrouji no I did your way and its working for now. Thanks.
If I found something than will update her.

[semy]

Same here… Hard reload in Safari and on iOS in my case are very often not working. This always happens when the access token event is not fired.

[semy]

Maybe some kind of race condition

[Fundstatapp]

Hey I have the exact same issue where when I enter the application for the first time after logging in I'm not receiving any payloads (status is correctly subscribed for the channel) and I've noticed that it might be because the first connection that is created in the realtime schema under subscription table is created as anon role, although I'm already in the application and I'm authenticated because everything else is loading correctly.

And then when I change pages and come back to the realtime page again I have correct authenticated connection and then payload works because it can correctly see the RLS for auth user.

The fix mentioned above worked for me where I open a dummy channel first and then the dummy is created as anon and the next is created as authenticated, but it would be great to have a permanent fix for it.

@supabase/supabase-js": "2.58.0",
@supabase/ssr": "0.7.0"

And my instances are already on the new asymmetric keys.