Add Live Real-Time Updates to a Supabase App
Your app already talks to Supabase, but right now nothing shows up until someone refreshes the page. This mission wires up Supabase's real-time system so changes appear the instant they happen. You'll turn on live updates for a table, send lightweight broadcast messages between connected users, and show who's online right now. By the end you'll have two open browser tabs updating each other automatically, with no refresh in sight.
Who this is for: Anyone with a working Supabase table who wants their app to update instantly when the data changes, without refreshing the page.
By the end, you'll have:
- A table with real-time enabled, streaming insert and update events to a connected client
- A private broadcast channel sending messages between two open tabs, protected by a real realtime policy
- A live presence list showing exactly who is connected right now
- A database trigger that broadcasts on writes, tested end to end with a working replay setup
What you'll learn:
- The difference between postgres_changes, broadcast, and presence, and when to reach for each
- How to subscribe to insert, update, and delete events on a table with a single filter
- How to write a realtime policy that controls who can send and receive broadcast messages
- How to track and read presence state for connected users
- Why broadcast from database exists and how it scales past what postgres_changes can handle
The journey
3 objectives. One real outcome.
Objective 1
Turn On Postgres Changes
Enable real-time on a table and listen for insert, update, and delete events as they happen.
Objective 2
Send Broadcast Messages and Track Presence
Send lightweight messages between connected clients and show who is online right now.
Objective 3
Scale Up with Broadcast from Database
Trigger broadcasts from database writes so complex logic and joins can drive real-time updates at scale.
Frequently asked questions
Do I need a paid Supabase plan for this?
No, real-time is available on the free tier and everything here works on it.
What's the real difference between broadcast and postgres_changes?
postgres_changes watches your database table directly. Broadcast sends messages that never touch a table at all, which makes it faster for things like cursor positions.
Can I filter which rows trigger a real-time update?
Yes, but only one filter per subscription, so plan your channel around a single condition.
Will postgres_changes slow things down as my app grows?
It checks permissions on every single event, which gets expensive at scale. That's exactly why broadcast from database exists.
Do I need to write backend code for this?
Just a bit of SQL for the trigger-based section. Everything else happens in your existing app code.