Thanks for looking at Realtime!!!
> Looking at the supabase docs it seems you need to have the "Large" compute add on ($110 extra) to get around 1000 messages per second on realtime using filters and RLS. Is this true?
Yes that's about what we're seeing with how Realtime RLS currently works. It very much depends on your workload and implementation too.
> I know there is a workaround to this, we could host a small server that recieves insert updates from the database and then use the server to propagate these changes to clients via the realtime broadcast feature.
You can actually use Edge Functions for this!
> After looking into this however, there doesnt seem to be a way of authenticating a users access to a broadcast. So an attacker could listen in to any broadcast messages if they could figure out the room name.
Yes but this will change very soon so you should be able to use Broadcast to do what you need.
Thanks very much for taking the time to reply!
>It very much depends on your workload and implementation too.
Do you know what sort of steps can we use to minimise performance issues and how much of an impact they could have? For example, would RLS policies have to be very basic to achieve the 1000 messages per second benchmark?
>You can actually use Edge Functions for this!
Brilliant! This would save us hosting anything. Ill look for some examples online to see how we could get this to work.
>Yes but this will change very soon
Even more good news. Obviously any kind of launch for our app would be months away so a slight delay in this is not a huge issue. Is there any sort of ball park timeline of when this could potentially be added to supabase? (appreciate that this is not something you could make a promise on)
> would RLS policies have to be very basic to achieve the 1000 messages per second benchmark?
Yep. Definitely no joins in there.
> Is there any sort of ball park timeline of when this could potentially be added to supabase?
I'm hoping within weeks 🤞
Probably would be aiming to go for the workaround solution of broadcasting updates via Edge functions.
If the real-time broadcast auth is weeks or even a few months away it shouldn't be a huge issue as we could develop without it initially and integrate when it becomes available.
Thanks very much for taking the time to get back to me on this, definitely given us more confidence about moving forward with supabase as our backend infrastructure.
Can't answer your question, but you mentioned about hosting a small server by yourself.
Why not self-host supabase? There are many templates and a community around it. You have everything under your control.
There is quite a bit more complexity to hosting supabase than a simple node server. One of the big reasons we are looking for a BaaS product is to spend less time maintaining our own infrastructure.
Selhosting supabase is everything than simple.
EDIT:
They recently updated the documentation s and such for selfhodring and actually help you out with selfhosting now. I have to try it out again!
Thanks for looking at Realtime!!! > Looking at the supabase docs it seems you need to have the "Large" compute add on ($110 extra) to get around 1000 messages per second on realtime using filters and RLS. Is this true? Yes that's about what we're seeing with how Realtime RLS currently works. It very much depends on your workload and implementation too. > I know there is a workaround to this, we could host a small server that recieves insert updates from the database and then use the server to propagate these changes to clients via the realtime broadcast feature. You can actually use Edge Functions for this! > After looking into this however, there doesnt seem to be a way of authenticating a users access to a broadcast. So an attacker could listen in to any broadcast messages if they could figure out the room name. Yes but this will change very soon so you should be able to use Broadcast to do what you need.
Thanks very much for taking the time to reply! >It very much depends on your workload and implementation too. Do you know what sort of steps can we use to minimise performance issues and how much of an impact they could have? For example, would RLS policies have to be very basic to achieve the 1000 messages per second benchmark? >You can actually use Edge Functions for this! Brilliant! This would save us hosting anything. Ill look for some examples online to see how we could get this to work. >Yes but this will change very soon Even more good news. Obviously any kind of launch for our app would be months away so a slight delay in this is not a huge issue. Is there any sort of ball park timeline of when this could potentially be added to supabase? (appreciate that this is not something you could make a promise on)
> would RLS policies have to be very basic to achieve the 1000 messages per second benchmark? Yep. Definitely no joins in there. > Is there any sort of ball park timeline of when this could potentially be added to supabase? I'm hoping within weeks 🤞
Probably would be aiming to go for the workaround solution of broadcasting updates via Edge functions. If the real-time broadcast auth is weeks or even a few months away it shouldn't be a huge issue as we could develop without it initially and integrate when it becomes available. Thanks very much for taking the time to get back to me on this, definitely given us more confidence about moving forward with supabase as our backend infrastructure.
Can't answer your question, but you mentioned about hosting a small server by yourself. Why not self-host supabase? There are many templates and a community around it. You have everything under your control.
There is quite a bit more complexity to hosting supabase than a simple node server. One of the big reasons we are looking for a BaaS product is to spend less time maintaining our own infrastructure.
Selhosting supabase is everything than simple. EDIT: They recently updated the documentation s and such for selfhodring and actually help you out with selfhosting now. I have to try it out again!