Real-time applications do not all need the same type of event.
Sometimes users need to know that database data changed.
Other times they simply need a temporary event.
This is where Broadcast and database changes serve different purposes.
Database Changes
Database change events are useful when the database itself is the source of truth.
For example:
New message inserted
↓
Realtime event
↓
Chat UI updates
The event corresponds to an actual database operation.
Broadcast
Broadcast is useful for sending real-time messages between connected clients.
Examples include:
Typing...
Cursor moved
User selected item
Temporary notification
These events do not necessarily need to become database records.
A Chat Example
A chat application might use database changes for:
New message
Message edited
Message deleted
And Broadcast for:
User is typing
Why Separate Them?
Not every temporary event belongs in your database.
Saving every typing indicator would create unnecessary data.
Architecture
A practical architecture can look like:
Permanent data → PostgreSQL
Temporary events → Broadcast
Choosing the Right Approach
Ask:
Does this event need to be stored?
If yes, database-backed events may make sense.
If no, a realtime broadcast can be more appropriate.
Final Thoughts
Broadcast and database changes are not necessarily alternatives.
A single application can use both for different parts of the user experience.