AskVibeSeparate issue: postgres_changes checks RLS for every subscriber on every change. 200 subscribers means 200 authorization checks per inserted answer, and that's done on a single thread. For a live quiz, have the players only insert, and let only the big screen subscribe. Or use Broadcast instead of postgres_changes for the live part, it doesn't hit the database at all.
Demo, all content is generated
Question
Will Supabase realtime hold 200 people in a live quiz on the free plan?
I run a pub quiz and built a little app where players join with a code and answers show up live on the big screen. Last time we had 60 players and it was fine. Next month it's a charity night with maybe 200 phones. Each phone subscribes to the answers table with postgres_changes. Is that going to break?
What I’ve tried
Read the pricing page, it mentions concurrent connections but I don't understand if a phone is one connection or more.
Is every phone subscribing, or only the big screen? deploydan · edited
every phone right now ifeoma · edited
3 answers
One browser tab with one supabase client is one realtime connection, no matter how many channels it joins. The free plan quota is 200 concurrent realtime connections, so 200 phones plus your big screen is right at the edge. Late joiners or people reconnecting after their screen locks would get refused.
For one night I'd just upgrade to Pro for the month (500 concurrent) and downgrade after. Cheaper than debugging it live.
Didn't know you can upgrade for one month. That's cheaper than the pizza. ifeoma · edited