Your users are waiting for the page to catch up. Not a full reload, just the number in the corner to change or a collaborator's cursor to appear. The gap between a database write and a client render is where real-time decisions either age well or turn into rewrites. Before you pick a vendor, write down one sentence: "When X happens, user Y must see Z within N seconds, even if they were offline for a minute." That sentence decides most of what follows.
I haven't shipped all three tools in a product described on this site. This comparison is based on vendor documentation checked on 10 October 2026. The question is what happens on reconnect and where the source of truth lives, not which demo looks quickest.
If your data already lives in Postgres, Supabase Realtime may be a useful starting point without another service. Shared-document editing and custom room logic need different models. Pick by the behavior your user needs, not by the popularity of a database.
What are the Supabase Realtime limits and pricing?
Supabase Realtime has three modes (Broadcast, Presence, Postgres Changes), and its per-plan limits are published: Pro allows 500 concurrent connections and 500 messages per second, while Free allows 200 and 100.
If your feature is "when row X changes, client Y should see it", such as a dashboard that updates when an order lands, Supabase Realtime fits. Broadcast is low-latency messaging between clients, Presence tracks who is online, and Postgres Changes streams database mutations.
Here are the limits from the Realtime limits page side by side:
| Limit | Free | Pro | Team |
|---|---|---|---|
| Concurrent connections | 200 | 500 | 10,000 |
| Messages per second | 100 | 500 | 2,500 |
| Presence messages per second | 20 | 50 | 1,000 |
| Presence calls per client, per 30 s | 5 | 5 | 5 |
| Presence keys per object | 10 | 10 | 10 |
On the pricing page, Free includes 2 million messages; Pro and Team include 5 million, with published overage of $2.50 per million messages and $10 per 1,000 peak connections. Do not confuse billing with the connection cap: the limits page lists 500 concurrent connections on Pro with a spend cap and 10,000 without one. Confirm your project's limit and spend-cap settings before forecasting traffic or overage. Presence can also constrain a sudden join burst.
How does Postgres Changes scale, and what about missed messages?
Postgres Changes authorizes every event against each subscriber: one change on a table with 100 subscribers triggers 100 authorization checks. The same page says changes are processed on a single thread to preserve order, so bigger compute add-ons don't meaningfully raise throughput, and it recommends Broadcast once you expect more than about 3,000 concurrent subscribers on the same changes.
If you already run the React + Supabase RLS stack, this ties your policy complexity to your real-time ceiling: expensive RLS policies get evaluated once per subscriber per event. My recommendation: keep policies on realtime-subscribed tables simple, or stream changes through Broadcast.
The pages I read don't promise that a client which drops and reconnects receives what it missed on Postgres Changes. The limits page does list Broadcast replay (72 hours retention, 25 messages per request). So design for it: on every reconnect, refetch current state before you trust the stream. That's an inference from the docs, and it costs you one query.
Is Realtime authorization automatic?
No. Realtime Authorization works through RLS policies on the `realtime.messages` table, and it's opt-in: you turn off "Allow public access" in Realtime Settings and create channels with `private: true`. For a multi-tenant product, test that a user from tenant A can't join a channel topic that belongs to tenant B.
Is Liveblocks worth the cost for collaborative UI?
Liveblocks earns its price when several people edit shared state at once and you'd rather not build conflict resolution yourself. Its pricing page lists Pro at $30/month ($25 billed annually) with $30 in monthly credits.
The differentiator is the data model. The multiplayer page describes conflict-free data types where concurrent edits merge automatically, presence for every connected user, and offline editing that syncs on reconnect. For rich text, it lists Yjs-compatible editors such as ProseMirror, Slate, Quill, CodeMirror and Monaco. Comments and notifications are metered features on top.
Metered rates on the same page: $0.002 per collaboration minute, $0.01 per comment, $0.005 per custom notification event. The Free plan has hard caps per meter, such as 3,000 collaboration minutes and 200 comments. Room size is the limit that surprises people: 10 simultaneous connections per room on Free and Pro, 50 on Team, 100 on Enterprise.
Liveblocks counts collaboration minutes only when at least two people or agents share a room; each connected user-minute counts, while a solo session does not. If 500 users each spend 20 minutes actively collaborating in a month, that is 10,000 billable minutes, or $20 at the listed rate, before other metered features. At 5,000 such users, it becomes 100,000 minutes, or $200. The Pro plan's $30 credits offset usage, not a room-size limit. Compare your real shared-session minutes and other meters before picking a plan.
The room limit matters more than price for some products. A shared workspace where 25 people are online together exceeds Pro's 10 connections per room, which points you to Team or a different design. I'd pick Liveblocks when collaboration is the feature users pay for, as in co-editing or a whiteboard. A dashboard that refreshes every few seconds doesn't need conflict-free types. The SaaS MVP stack rarely does either.
When should you choose PartyServer instead?
Choose PartyServer when you need custom per-room server logic: a multiplayer protocol, specialized message routing, or state transitions that database notifications and a managed editor do not provide. PartyServer is the successor to PartyKit. It keeps rooms, connections, broadcasting and hibernation, but deploys as a Cloudflare Worker with Durable Objects in your own account.
This is no longer a choice between three unchanged hosted products. PartyKit's managed platform stopped accepting new projects on 9 October 2026; its migration timeline says deployments stop on 16 October and hosting shuts down on 23 October. If you already use PartyKit, export room data and move to PartyServer before those deadlines. If you are starting today, start with PartyServer, not a new PartyKit deployment.
What do you own with PartyServer?
You write the server handlers, authorization and reconciliation rules. The migration guide shows a Server class from partyserver, deployment with wrangler, and a Durable Object binding in wrangler.jsonc. Its example keeps static options = { hibernate: true }. Check who can join each room and what a reconnecting client must reload; the framework does not make your application state correct by itself.
The old PartyKit hibernation guide described up to 32,000 connections per room with hibernation versus 100 without, but it explicitly says the practical maximum depends on code and memory. Treat those as platform guidance for that implementation, not a throughput guarantee for a new PartyServer app. Load-test your own room size.
What will it cost?
PartyServer runs on Cloudflare, so model both Workers and Durable Objects pricing. On the paid Durable Objects plan, the published allowance is 1 million requests and 400,000 GB-seconds a month, then $0.15 per million requests and $12.50 per million GB-seconds. WebSocket messages have their own billing conversion described on that page; multiplying raw messages by the request rate directly would be wrong. Hibernation can reduce duration charges when rooms are idle, but storage and Workers usage also matter. Use Cloudflare's worked examples and your expected room activity before calling it cheaper than Liveblocks.
Supabase Realtime vs Liveblocks vs PartyServer: which fits your product?
Pick by the job: Supabase Realtime for pushing database changes you already own, Liveblocks for managed co-editing, PartyServer for custom server logic you're willing to maintain.
| Supabase Realtime | Liveblocks | PartyServer | |
|---|---|---|---|
| Primary model | Database changes, Broadcast, Presence | Conflict-free collaborative rooms | Custom WebSocket server per room |
| Conflict handling | You design it | Built in | You write it |
| Presence | Built in (rate-limited) | Built in | You write it |
| Billing unit | Connections and messages | Collaboration minutes, comments, events | Cloudflare requests and GB-seconds |
| Room/connection ceiling | 500 on Pro with spend cap; 10,000 without | 10 per room on Pro | Depends on room workload; load-test your design |
| Custom server logic | Database functions and policies | Server-side document edits; managed room protocol | Full room protocol control |
Three examples show the boundary. A booking dashboard can use Supabase Realtime to show confirmed reservations, with a refetch on reconnect. The BookBed case study describes overbooking detection with Flutter, Firebase and Stripe, not Supabase Realtime. A seat picker where two buyers may claim the same seat needs an authoritative database transaction or constraint; Liveblocks' conflict-free editing cannot guarantee one successful purchase. A shared text editor is a better Liveblocks example. A multiplayer annotation tool with a custom protocol is where PartyServer's flexibility may justify the extra code.
If you're on Supabase already, start there and move only the feature that hits a limit. If Postgres Changes hits the per-subscriber authorization cost, switch that feature to Broadcast and keep the same infrastructure.
Your next step today: open a staging build, disconnect a client while writes are happening, wait a minute, reconnect, and look at the UI. Does it show stale data without saying so? Fix that before you compare prices.