Realtime delivery is intermittent on a Pro project. Subscriptions receive postgres_changes events for a few minutes, then go silent with no client-side error. Had to fall back to polling.
Diagnostics over a short window, no changes made on my side:
A few minutes ago pg_replication_slots showed the expected pair, both active:
..._messages_replication_slot_v2... | pgoutput | logical | active=true ..._replication_slot_v2... | wal2json | logical | active=true
Minutes later, same database:
SELECT * FROM pg_replication_slots; → 0 rows SELECT count(*) FROM pg_stat_replication; → 0 (no walsender) count of objects in the _realtime schema → 0 (looks unprovisioned) Meanwhile the publication is correct and stable:
pg_publication_tables for supabase_realtime → 8 tables Subscribed tables have REPLICA IDENTITY FULL So the Postgres-side publication is fine, but the Realtime slots appear/disappear on their own and _realtime looks empty. Seems like a Realtime tenant provisioning / control-plane issue rather than a DB config problem.
Already ruled out: publication + REPLICA IDENTITY FULL confirmed, RLS verified, standard SDK, project restarted (slots still flap).
Questions:
Has anyone seen replication slots flap like this (active → absent) with an empty _realtime schema? Is this a known Realtime tenant provisioning failure, and what's the fix beyond a project restart? Did it self-recover for anyone, or did it require Supabase to re-provision the tenant?
The user reports intermittent realtime delivery issues on a Pro project, where subscriptions receive events for a few minutes before going silent without errors. Diagnostics show replication slots flapping between active and absent states, suggesting a potential Realtime tenant provisioning issue. The user seeks insights on whether this is a known issue and how to resolve it beyond restarting the project.