Realtime and collaboration Explained and Compared

How do you keep two people’s screens in sync?

Start with a shared task board. When one teammate marks a task done, the other should see the saved change without refreshing. Decide what the second person sees when their connection drops and whether someone outside the board can receive its updates.

Which changes need to appear right away?

A subscription keeps the app listening for new information while the screen is open. Choose it for the changes a person needs during that task. A weekly report may be fine with a fresh read when they open it.

Decide what should last after someone closes the page
What people see	How the app should handle it
A task was marked done	Save the task status so the next person who opens the board can read it.
A teammate is viewing the board	Use temporary presence information. Show it only to people who are allowed to know who’s there.
Two people typed different task titles	Choose how the app handles a competing change. Keep the current title, ask before overwriting it, or design how to merge edits.

Can signing in reveal a board someone doesn’t belong to?

Signing in tells the app who the person is. A separate permission check decides which boards they may read or change. Apply that check when the app first loads the board and when it asks for live updates.

A hidden menu or a board address that is hard to guess does not protect the records. Test the board itself using a signed-in account that belongs to a different board. If you show who is viewing or typing, limit that information to the same authorized group.

Compare tools

Scroll the table sideways to read every column.

Ways to keep a shared task board current
Tool	What does the screen listen to?What the app connects to for updates.	Where do you check access?How to keep an update inside the right board.	How does the screen catch up?What happens when someone returns after a disconnect.	What usage should you watch?What the service can count as the board gets busier.
Supabase	Listen to Postgres row changes or send a message on a Broadcast channel when a row changes.	Use table rules for Postgres Changes. For Broadcast, enforce private channels and set separate rules for who can receive messages on each board’s channel.	Have the app re-read the saved board after reconnecting so the screen doesn’t depend on every event arriving.	Watch Realtime messages and the highest number of simultaneous connections.
Firebase	Use a Cloud Firestore snapshot listener for one record or a set of matching records.	For the browser app, write a query that fits Firestore Security Rules. The rules can reject the whole query.	Firestore can show cached data and sync local changes on reconnect. Its documented offline behavior for competing changes to the same document is last write wins.	Watch document and applicable index reads. Reconnect billing depends on offline persistence.
Convex	Subscribe to a query, a function that reads the board. Convex sends a new result when the data it used changes.	Check board membership in the functions that return or change its records.	The React client reconnects automatically and resumes the session. Test how your app shows stale data and confirms saved edits.	Watch function calls and database reads and writes. Cached reads do not count toward database bandwidth.
Ably	Subscribe to an Ably channel for board events. Read the saved board from your app.	Have your server issue short-lived tokens scoped to the board and permitted operations.	The library can resume a short interruption. Re-read the saved board if it cannot recover.	Check monthly active users on current public packages and account limits for connections and bandwidth.
Pusher Channels	Subscribe to a Pusher Channels channel. Your app saves and reads the board.	Your server checks board membership before authorizing a private subscription.	Re-read the board after reconnecting. A cache channel can return the last event, when available.	Watch daily messages sent and delivered and the highest number of simultaneous connections.
Socket.IO	Listen for events from a Socket.IO server you operate. The server can send updates to a room.	Check identity and board membership before the server admits a connection to a room.	Missed events aren’t replayed by default. Re-read saved state and check any optional recovery setup.	Budget for connections, message traffic and the infrastructure that runs and connects your servers.
Liveblocks	Connect to a Liveblocks room. With its Yjs integration, the service stores and syncs the draft.	Sign users in through your app. Set private room permissions or grant room access when your server issues tokens.	Reconnect and wait for the draft to sync. Reopening offline needs a separate test of the experimental browser storage option.	Watch collaboration minutes, active rooms, simultaneous connections and storage.
Yjs	Connect an editor and a provider that carries updates. Choose where the draft is saved.	Have the connection backend verify who can read or write the document. The core library combines edits.	Let the provider exchange missing edits after reconnecting. Add browser-local persistence if drafts must survive reopening.	No library fee. Budget for the chosen connection provider, storage and upkeep.
Automerge	Connect an Automerge Repo to a network adapter and choose where it saves documents.	Authenticate the connecting account and check document access before sharing a copy.	Exchange changes when the connection returns. Check how your app handles two edits to the same field.	Budget for your sync server or service, storage and backups. The core library is MIT-licensed.
LiveKit	Join a room for live audio, video or short messages. Save app records separately.	Check membership before issuing a room token. Grant publish and receive permissions separately.	Reconnect the call and check fresh audio. Keep any chat history or meeting notes separately.	Cloud counts participant minutes and data sent out. Recording and export have separate usage.

What should happen when someone comes back online?

Show when the board may be out of date. After the connection returns, confirm that the screen reaches the current saved state, even if it missed several changes. A saved copy on the device can help someone keep reading while offline. A change that is still waiting to sync should look different from one the server has accepted.

For a shared task title, one possible rule is to reject an edit based on an older version and offer the current title plus the person’s unsaved text. Two people can both see updates promptly and still overwrite each other if the write rules allow it. For shared documents where people expect their text changes to combine, evaluate a dedicated collaborative editor and its merge behavior.

How can you test a shared board before inviting anyone?

Use a disposable app and a board with made-up tasks. Before opening it, verify that sign-in, records and any messages or analytics use only test services. Use two test accounts that belong to the board and a third that belongs to a different board. If you cannot verify the setup, sketch the three screens and their expected results on paper.

Watch a saved change arrive
Open the same board in two separate browser profiles. Mark a task done in the first. Confirm the second shows Done without reloading, then reopen the board to check that Done was saved.
Check the return from offline
Disconnect only the second test browser. In the first, save a different status. Check that the disconnected screen shows it may be out of date. Reconnect it and check that it catches up to the saved status.
Try two changes to the same title
Open the same title for editing in both sessions. Save a new title in the first, then try to save a different title from the older edit in the second. Check the outcome against the rule you chose, including what happens to the second person’s text.
Try to read the board as a nonmember
In a fresh third browser profile, sign in as the nonmember and open the test board address. Confirm the app attempted to load the board and the service returned no board records for this account. If the screen stops before it makes the request, check the read separately in the test setup.
Check the live subscription separately
Check whether the nonmember session actually asked to receive updates for the test board. While a member changes a task, confirm an authorized listener gets the update and the nonmember gets no board data. If the screen never asks to subscribe, record the subscription as untested. Add a separate authorization test in the same disposable setup that subscribes as the nonmember with normal account permissions, then checks that no board updates are delivered.

What happens to usage when people leave the board open?

Compare what the service counts before comparing prices. Start by listening only to the records the current board needs. Stop listening when someone leaves the board if the rest of the app has no reason to keep receiving those updates.

For example, Firestore charges reads when a matching record is added or updated, and can charge new-query reads on reconnect. For mobile and web listeners, a reconnect is billed like a new query after more than 30 minutes away when offline persistence is enabled, or on each reconnect when it’s disabled. Convex counts function calls and database input and output separately. Convex documents no database bandwidth charge for cached reads. The usage of one test board does not predict the bill for every workload.