Clarification about Supabase Realtime limits
Hey everyone, I'm curious about and would like some clarification on Supabase Realtime's rate limits. I REALLY think that the way the pricing structure is set up on the page of turning people away from becoming paid users, and I have seen multiple posts and comments to validate that thinking. So as for my own confusion, I know that the free plan supports up to 200 concurrent connections, and the Pro Plan support of to 500 with every 1000 over that costing $10.
What I don't know, is what that looks like in a typical medium scale application, because you say the Pro Plan can support up to 100k monthly active users, so am I to believe that it's rare for there to be 500 concurrent connections in an application with 90k users? There needs to be some clarification about what makes a concurrent connections with examples, and what a high scale scenario looks like.
Is a connection something that stays open long enough for a bunch to pile up in a single day? Or is this something like a millisecond event? That's my main question, how long does a typical event last. Also, someone was telling me that you can only subscribe to one table at a time with Realtime, which seems....wrong.
7 Replies
Build locally first.
I can't comment on Supabase's pricing strategy. But a connection is the websocket from a client to the realtime server. It stays open as long as you keep it open, or until you leave the client, or the client goes to background/sleep long enough for it to disconnect.
There is one websocket normally per client with many channels.
I don't see how that answers my question lmao
I misread sorry lol
You're good haha
you can subscribe to multiple tables at a time in supabase
https://github.com/orgs/supabase/discussions/2268
GitHub
Can you subscribe to more than one but not all tables on realtime? ...
On the docs you can see 2 options: All tables: const mySubscription = supabase .from('') .on('', payload => { console.log('Change received!', payload) }) .subscribe() O...
All unique things like tables, filters, schemas with postgres changes are a channel. So are broadcast and presence features. All of those will run on 1 connection per client.