best practices for updating/getting data in real time
I'm about to build my first Supabase app with PostgreSQL. I want to make sure my users always get their data in real time. For example, if someone changes the data, it should instantly show up for other users.
What's the best way to do that, Broadcasts or Postgres Changes? I'm basically looking for the equivalent of a Firebase Firestore snapshot listener.
7 Replies
Realtime | Supabase Docs
Send and receive messages to connected clients.
Broadcast from the database is the recommended way now instead of postgres_changes. You can use a trigger to format the data on a table change to include other table joins if need be.
That is close as you will get to firebase snapshots.
Postgres changes monitors a single table and you have to deal with assembling it into your existing data. If you have multiple tables involved then you need multiple channels for each. The broadcast trigger method works like that by default, but because you control the trigger function you can add other data to send to the clients. Note it will still be a row usually and not an entire query structure being updated. You will also have to deal with missed data while the connection is off and on errors. You would reload anything missed after you have a new connection going. If I recall Firebase handles that for you.
Postgres changes monitors a single table and you have to deal with assembling it into your existing data. If you have multiple tables involved then you need multiple channels for each. The broadcast trigger method works like that by default, but because you control the trigger function you can add other data to send to the clients. Note it will still be a row usually and not an entire query structure being updated. You will also have to deal with missed data while the connection is off and on errors. You would reload anything missed after you have a new connection going. If I recall Firebase handles that for you.
Thanks, appreciate it! So does that basically mean Postgres changes is just the older version for handling real-time data and not recommended anymore? So the newer, more modern approach would be to use Broadcast?
And what about security with Broadcast? Does Supabase handle that automatically?
Read the link tomaspozo added. It covers broadcast private channels. This means RLS is enforced on the channel versus every operation which postgres_changes does. This makes it faster, more scalable.
The docs recommend new cases use broadcast from DB for those reasons. But it is a higher learning curve.
I got a question on broadcast and RLS. I checked the yt tutorial on RLS with broadcast.
If i understand correctly any user can start or join a channel/topic.
With RLS you can restraint who can read or write messages to a channel
And the only way to determine if a user is allowed or not is by using the topic as some sort of key? Like having the current project id as the topic and in the rls check if the user can see the project
Am i wrong about my understanding ?
With private broadcasts they can't start or join a channel unless you allow RLS on the realtime.messages tables allowing them to.
With Postgres_changes (the older way) anyone can join a channel then RLS was checked on each method.
So you can allow by auth.uid() against a table of chat users where to join the chat they have to be in the table for a specific channel(s). You can have a channel all users can subscribe too, but only the DB or service role can send. Pretty much what ever you come up with for an RLS policy separately for sending and receiving on the channel.
I have a setup to allow user to follow the progress of a job
The way i have it setup right now without RLS, the user creates a channel called job_uuidofthejob
And i have an edge function that sends a message to the same channel
If i want to make it private with RLS
I don't want the user to write so i would just not allow that one.
And for read , id extract the uuid of the job from the topic and use the auth.uid() to check if they are allowed.
Is this how you would do it?