Realtime is about connected users
WebSocket-style services keep a live connection open so the server can push changes to browsers or apps immediately.
Realtime and WebSocket Services
Best Free Realtime & WebSockets Cloud Platforms 2026
Realtime services are for live user experiences: chat, presence, collaborative editors, dashboards, notifications, and multiplayer state. The free-tier bottleneck is usually simultaneous connections and message bursts, not storage.
Fast answer
Use Supabase Realtime when Postgres changes drive UI updates.
Use Ably for general chat, presence, and collaboration.
Use MQ instead if the work must be durable and retryable.
Last Updated: 2026-05-22
Mental model
Connection count is the first limit
For realtime apps, 200 peak connections may matter more than millions of monthly messages.
Presence is different from persistence
Realtime services can tell who is online and broadcast changes, but durable messages and history still need storage.
Realtime is not a background queue
Use queues for durable async jobs. Use WebSockets when users need live feedback in the UI.
Quick recommendations
Best Postgres-backed realtime
Supabase Realtime
Good when UI updates should follow database changes and your app already uses Supabase/Postgres.
Best general realtime network
Ably
Good for chat, collaboration, presence, global fan-out, and managed realtime infrastructure.
Best GraphQL subscription path
AWS AppSync
Good when the app is already in AWS and GraphQL subscriptions fit the data model.
Best classic Channels ecosystem
Pusher Channels
Good for conventional WebSocket channels and a familiar SDK ecosystem, with strict connection caps.
Free realtime and WebSocket comparison table
Use this table for connection and message limits. For real apps, plan reconnect, fallback, and durable history separately.
| PROVIDER | FREE STORAGE | MONTHLY BANDWIDTH | SPECS / COMPUTE | CONNECTION LIMITS | KEY CONSTRAINTS | ACTION |
|---|---|---|---|---|---|---|
Supabase RealtimeDATABASE CDC / WEBSOCKET | 200 Peak Conns | 2,000,000 Realtime Messages / Month included | Native PostgreSQL CDC tracking; triggers automatic frontend push on DB mutations | Hard cap at 200 simultaneous listener channels | Exceeding 200 concurrent active users causes new arrivals to instantly drop real-time features | Go to Site ↗ |
Ably RealtimeENTERPRISE PUB-SUB | 200 Peak Conns | 6,000,000 Messages / Month (Industry leader free tier allocation) | Global edge state synchronization mesh, native intelligent reconnection tracking | Hard lock at 200 active client connections | Strict 500 messages/second burst cap; excess messages silently discarded under heavy traffic spikes | Go to Site ↗ |
AWS AppSyncGRAPHQL SUBSCRIPTION | 600k Conn-Mins | 250,000 Updates / mo free for the first 12 months | Managed GraphQL and serverless Pub/Sub Events API with deep AWS IAM security integration | Dynamic auto-scaling infrastructure connection limits | Not Always Free; tier expires strictly after 12 months, post-expiry pay-per-call metrics are complex | Go to Site ↗ |
Azure Web PubSubMANAGED WEBSOCKET | 20 Peak Conns | 20,000 Messages / Day (Always Free tier) | Native WebSocket fallback protocol orchestration, zero infrastructure provisioning | Strictly capped at max 20 concurrent active socket connections | Extremely low connection ceiling; the 21st listener hits a hard 503 error. Lacks custom domain mappings | Go to Site ↗ |
Pusher ChannelsSTANDARD WEB-SOCKET | 100 Peak Conns | 200,000 Messages / Day rolling sandbox | Industry-standard WebSocket framing API, richest third-party open-source SDK wrapper ecosystem | Hard physical socket limit at exactly 100 concurrent listeners | The 101st user receives an explicit front-end connection error; requires immediate manual upgrades | Go to Site ↗ |
How to choose realtime services
Estimate concurrent users first
Realtime free tiers are usually constrained by simultaneous connections. A quiet app with many logged-in users may still exceed connection caps.
Separate live state from history
Use realtime transport for live updates, and use a database or object storage for durable message history and audit trails.
Handle reconnects and missed events
Mobile networks drop. Browsers sleep. Your app needs resync logic, sequence numbers, or database refresh after reconnect.
Budget messages per user action
Typing, cursor movement, presence, reactions, and document edits can multiply message volume faster than expected.
Realtime traps
Presence can cost more than chat
Heartbeats, join/leave events, and reconnects can create heavy message volume even when users are not sending visible messages.
Connection caps fail visibly
When the 201st user cannot connect, the realtime feature fails in the UI. Design graceful fallback states.
Database CDC is not free fan-out
Pushing every table mutation to every client can overwhelm quotas. Filter channels and send only useful changes.
Realtime does not guarantee delivery history
Many realtime services optimize live delivery. If offline users must catch up, store events durably elsewhere.
Recommended realtime patterns
Supabase Realtime + Postgres
A compact stack for dashboards and collaborative data views where database changes should update the UI.
Ably + durable message store
Use Ably for live fan-out and a database for message history, search, moderation, and audit.
WebSocket + queue fallback
Use realtime for online delivery and MQ for background processing, retries, and durable workflows.
Related categories
Realtime FAQ
What are WebSockets used for?+
They keep a live connection between client and server so apps can update instantly: chat, presence, collaboration, notifications, dashboards, multiplayer state, and live cursors.
What is the difference between realtime and MQ?+
Realtime is user-facing and connection-oriented. MQ is backend infrastructure for durable asynchronous processing.
Is Supabase Realtime enough for chat?+
It can work for small apps, especially if messages are stored in Postgres. Watch peak connections, message quota, and offline catch-up behavior.
What should I monitor in WebSocket apps?+
Monitor active connections, connection errors, reconnect rate, messages per second, dropped messages, latency, and per-channel fan-out.
Can WebSockets store message history?+
The transport itself does not solve durable history. Store chat history, audit logs, and offline events in a database or object storage.