Real-Time Broadcast and Pub/Sub Servers: Domain Explainer#

The hardware-store version#

A WebSocket library, covered in 1.067, is a telephone line: it connects one client to one server. A broadcast server is the switchboard. It knows who is on the line, which topics they care about, and how to pass one message to ten thousand listeners at once. Plenty of apps start with the telephone line and discover, around the second server or the first dropped connection, that they need the switchboard.

The problem#

A web request answers one question and ends. Anything that should arrive without being asked for (a new chat message, a price tick, a “your export is ready”) needs a connection that stays open, and something on the server that decides which connections receive which message.

Three things make this harder than it looks.

One server stops being enough. Connections live in one process’s memory. When two or more servers sit behind a load balancer, a message published on server A must also reach the clients connected to server B. That needs a shared channel between servers, called a backplane, and each framework solves it differently.

Networks drop. Phones go through tunnels and laptops sleep. A message sent while a client is disconnected is, by default, gone. Some systems keep a short history so a returning client can catch up; most do not, and the application must fetch what it missed.

Who is here? Chat, collaborative tools and live counters want a roster of connected users. Connections can vanish without saying goodbye, so a roster needs timeouts and reconciliation.

Approaches#

• A standalone fan-out service next to the application. The backend publishes over HTTP; browsers connect to the service. Examples: Centrifugo, Mercure.
• Realtime built into the app server. The application process holds the connections and shares messages between nodes through an adapter or its runtime. Examples: Socket.IO, Phoenix Channels.
• A general message bus with a browser door. A broker used for service-to-service messaging that also accepts WebSocket clients. Example: NATS.
• A protocol clone. A self-hosted server that speaks the API of a hosted service so existing clients keep working. Examples: Soketi and Laravel Reverb, which speak Pusher’s protocol.
• A hosted service. Ably, Pusher Channels and Supabase Realtime run all of it for a fee per message or connection. They appear in this survey only as the alternative to compare against.

Underneath most of these sits a pub/sub relay such as Redis pub/sub, which carries messages between server nodes.

How a message travels#

A backend event happens: a comment is saved. The backend tells the broadcast server which channel it belongs to, usually with one HTTP call or a function call into the framework. The server looks up which connections are subscribed to that channel and writes the message to each. If other server nodes hold more subscribers, it passes the message to them first through the backplane, and each node writes to its own connections. The client library on the other end turns the bytes into an event in the page.

Each step has a failure mode a buyer should ask about: the publish call can succeed while a subscriber is offline; the backplane can drop while the nodes keep running; a client can reconnect to a different node than before. The systems in this survey differ in which of these they repair for you.

Trade-offs across the whole category#

• Simplicity against capability. One-way Server-Sent Events (SSE) from a hub is the least to learn and run; two-way channels with history, presence and permissions need a real server and a client library.
• Embedded against separate. Realtime inside the application reuses its authentication and data model but ties connection count to the app’s deploy cycle. A separate service scales and restarts on its own, at the price of another moving part and a second auth path.
• Open against paid. Several of these have a free edition with a ceiling (a single node, fewer operations tools) and a paid one without. The ceiling is worth finding before design, not after.
• Own against hosted. A hosted service removes operations and bills by messages or connections. A self-hosted one bills by machines and attention.

Vocabulary#

• Channel, topic, room: the named group a message is addressed to. Different systems use different words.
• At-most-once: a message is delivered once or not at all. At-least-once: it is retried until acknowledged, so duplicates are possible.
• History and recovery: the server keeps recent messages and replays what a reconnecting client missed.
• Presence: the list of who is connected to a channel.
• Transport: the connection type. WebSocket is two-way and universal; SSE is one-way over plain HTTP with built-in reconnection; WebTransport is a newer two-way option over HTTP/3.

When you need one#

• Several app servers share connections.
• You want history, recovery or presence without writing them yourself.
• Updates must reach thousands of clients quickly.

When you do not#

• A single server with a few dozen connections is well served by a plain WebSocket library.
• If updates are rare and a few seconds late is fine, polling is simpler.
• If the only goal is a phone notification when the app is closed, that is mobile push (see 1.119.2), a different layer.

Sources#

The delivery vocabulary follows the documentation of Redis pub/sub (https://redis.io/docs/latest/develop/pubsub/), Socket.IO (https://socket.io/docs/v4/delivery-guarantees) and NATS JetStream (https://docs.nats.io/nats-concepts/jetstream). The backplane idea is described in the Socket.IO adapter documentation (https://socket.io/docs/v4/adapter/). The SSE and EventSource reconnection behavior is defined in the Mercure specification (https://mercure.rocks/spec). Server-Sent Events and WebTransport status were read from the sources cited in S4.

S1: The field at a glance#

Servers and frameworks that take a message from a backend (or another client) and fan it out to many connected browser and app clients. Client-library choice for a single WebSocket connection is covered in 1.067 WebSocket Libraries; this survey starts one layer up, where the question is channels, rooms, history, presence and more than one server.

Four shapes#

Redis pub/sub is not a client-facing server. It is the backplane several of the above use to share messages between nodes, and it is profiled that way.

Ably, Pusher Channels and Supabase Realtime are hosted services. They appear as neighbors in hosted-neighbors.md so a reader can see what self-hosting trades away; they are not scored.

Evaluation dimensions#

1. Delivery guarantee. At-most-once, at-least-once, ordered or not.
2. History and recovery. What a client gets back after a dropped connection.
3. Presence. Who is connected to a channel right now.
4. Horizontal scaling. What it takes to run two or more nodes, and which edition allows it.
5. Transports. WebSocket, SSE, HTTP streaming, WebTransport.
6. Authentication and authorization. How a client proves identity and which channels it may join.
7. License and viability. What the license obliges, and whether the project is still maintained.

Boundary#

In scope: self-hostable servers that fan out to browsers and mobile apps. Out of scope: document-state synchronization (CRDT libraries such as Yjs handle merging edits, and run on top of one of these transports), mobile push through APNs or FCM (see 1.119.2 Push Notification Libraries), task queues (see 1.043.1), and WebRTC media.

Facts below were read from vendor docs and the projects’ repositories on 2026-10-05 unless marked otherwise.

Centrifugo#

A standalone real-time messaging server written in Go. Your backend, in any language, publishes to it over an HTTP or gRPC API; clients subscribe to channels through official SDKs for JavaScript, Swift, Java, Dart, C# and Go (source: https://centrifugal.dev/docs/getting-started/introduction, accessed 2026-10-05). The same code base is available as a Go library, centrifuge (MIT).

Facts#

Behavior to know#

• Channels default to deny. A subscription from a client is refused until the channel’s namespace sets allow_subscribe_for_client, and an anonymous user also needs allow_subscribe_for_anonymous (measured 2026-10-05; Centrifugo 6.9.7; a subscribe without it returned code 103 permission denied).
• Recovery has two modes: stream mode replays every missed publication, cache mode delivers only the latest one. Cache mode suits dashboards and tickers (source: https://centrifugal.dev/docs/server/history_and_recovery).
• A recovered: false result tells the app to reload state from its own database. The docs call streams ephemeral.

Edition line#

PRO is a paid license, quoted on request, and adds push notification API, rate limiting, user blocking and token revocation APIs, tracing, SSO for the admin UI, and delta compression among others (source: https://centrifugal.dev/docs/pro/overview). The open-source edition already includes multi-node Redis scaling, history, presence and recovery.

Trade-offs#

• Strong on the features chat and feeds need, with the history model written down plainly.
• A separate process to deploy and a client SDK to adopt; the SDK is required for the bidirectional transports.
• History is a sliding window, not storage of record.

Hosted neighbors#

Not scored. These are the managed services the self-hosted options are usually weighed against. List prices were read on 2026-10-05 and change.

What self-hosting trades away#

• Operations. Connection capacity planning, TLS termination, a proxy that does not break WebSockets or SSE, and a backplane to run.
• Metering shape. Hosted prices scale with messages or connections; self-hosted cost scales with machines. Flat daily caps (Pusher) and per-message metering (Ably) behave differently under a burst.
• Protocol lock-in. The Pusher protocol is implemented by the Soketi and Reverb servers, so leaving Pusher Channels is cheap. Ably’s and Supabase’s client protocols are theirs; Centrifugo and Mercure are alternatives with different protocols.
• Features. Ably documents history and delivery features as a product; in the self-hosted set only Centrifugo (history and recovery) and NATS JetStream cover the same ground.

Mercure#

An open protocol and a reference hub for pushing updates to browsers over Server-Sent Events. A backend publishes with a plain HTTP POST; browsers subscribe with the native EventSource API, no client library required. The hub is a Go module that runs inside Caddy.

Facts#

Behavior to know#

• Version 1.0 changed authentication. The hub’s default configuration validates access tokens in a stricter mode (issuer, audience and scope claims, RFC 9068 style), and the legacy simple-JWT setup runs only under an explicit compatibility switch (measured 2026-10-05, v1.0.3: a token carrying only the classic mercure claim was rejected with 401 on the default configuration; the subscribe parameter topic was refused with a message pointing to match). Tutorials written for 0.x do not work unchanged.
• The cluster page states that open source, Cloud and Self-Hosted tiers speak the same protocol, so a client can move between them by changing the hub URL. Self-Hosted tiers are listed from 1,500 to 12,000 euros or more a year (source: https://mercure.rocks/docs/hub/cluster, accessed 2026-10-05).
• AGPL-3.0 obliges anyone who modifies the hub and offers it over a network to publish those modifications; running it unmodified behind an app creates no such duty for the app.

Trade-offs#

• Smallest client footprint: browsers, mobile webviews and any HTTP client work with no SDK.
• One-way only: clients receive; sending goes through your own HTTP endpoints.
• High availability is the paid line; free users run one node.

NATS with WebSocket#

A messaging system written in Go. Core NATS is subject-based publish/subscribe with request-reply; JetStream adds persistence. The server has a built-in WebSocket listener, so browsers connect straight to the broker with the JavaScript client.

Facts#

Behavior to know#

• A browser that connects to NATS speaks the broker’s own protocol with its subject model; there is no channel-permission layer designed for end users in the way Centrifugo or Pusher-style servers have one. Per-user subject permissions and auth callout are the tools for restricting what a browser can subscribe to.
• NATS is a good fit when the broker already carries internal traffic and the same subjects should also reach browsers. It is a heavier commitment than a fan-out gateway when nothing else uses it.
• Centrifugo can use NATS as its inter-node broker, without history or presence.

Trade-offs#

• Highest project velocity in the set and open-source clustering and persistence.
• Browser-facing concerns (presence, per-channel recovery for UI clients, user-scoped channels) are yours to assemble.

Phoenix Channels and PubSub#

The realtime layer of the Elixir web framework Phoenix. Channels give topic-based message routing over WebSocket (with long-polling as the only other transport); Phoenix.PubSub distributes broadcasts across nodes; Phoenix.Presence tracks who is on a topic.

Facts#

Behavior to know#

• The server and the app are the same program. Channels reuse the app’s authentication and database, which removes a network hop and a service boundary, and requires the backend to be Elixir.
• Clients are the Phoenix JavaScript library, plus community clients for Swift, Kotlin and others. The wire format is Phoenix’s own, so there is no generic client.
• Connections are Erlang processes. Fan-out cost per node comes from the BEAM scheduler; no benchmark for it is included here because this survey’s harness did not stand up an Elixir app.

Trade-offs#

• The most complete built-in presence story in the field, and clustering with no extra infrastructure.
• Not usable by a team that does not run Elixir; the Redis adapter is a niche escape hatch.
• No history means recovery is entirely your design.

Pusher-protocol servers: Soketi and Laravel Reverb#

The Pusher Channels protocol has two halves: a WebSocket client protocol with public, private and presence channels, and a signed HTTP API for publishing. Servers that implement it let an app switch from hosted Pusher to self-hosting by changing a host name. Presence channels and private-channel authorization are part of the protocol.

Soketi#

A Node.js server built on uWebSockets.js that implements Pusher protocol v7 (source: https://raw.githubusercontent.com/soketi/soketi/master/README.md, accessed 2026-10-05).

An issue titled “the Soketi project is abandoned” was opened 2024-02-11 and closed; a newer issue, “Is Soketi maintained?”, opened 2026-02-12 and was still open on 2026-10-05 (source: GitHub issues 1114 and 1305). The README says the project is meant to stay free and maintained. Read the durability signal as stalled: patches are arriving and none are merged.

Laravel Reverb#

A first-party Laravel WebSocket server in PHP on a ReactPHP event loop, speaking the Pusher protocol so Laravel Echo and Pusher clients work (source: https://laravel.com/docs/12.x/reverb).

Reverb is built for Laravel apps. It can serve other apps through the Pusher protocol, but its install path and monitoring (Pulse) assume Laravel.

What the protocol gives and withholds#

• Presence channels, private channels and client events: yes.
• History, replay after reconnect: no. Pusher Channels does not replay; apps refetch from their database.
• Delivery: at-most-once.

S1 recommendation: which shape fits which situation#

Findings that cut across the field#

1. Almost every server here is at-most-once. Centrifugo, Socket.IO, Phoenix, Mercure, Reverb and Redis pub/sub all say so in their docs. Replay after a gap is the feature that varies: Centrifugo (history stream), Socket.IO (state recovery on two adapters), Mercure (Last-Event-ID, best effort) and NATS JetStream have it; Phoenix and Pusher-protocol servers do not.
2. High availability sits on different sides of the license line. Centrifugo’s Redis-backed multi-node is in the Apache-2.0 edition, Phoenix clusters natively, NATS clusters in open source, and Mercure’s multi-node requires a paid Self-Hosted license.
3. The server’s protocol decides the client. Socket.IO, Phoenix, Centrifugo and NATS each need their own client library; Mercure needs none; Pusher-protocol servers reuse Pusher’s clients.
4. One project has stalled. Soketi shows 42 open PRs and none merged since October 2023, with no release since March 2024.
5. Licenses differ in what they ask. Apache-2.0 and MIT for Centrifugo, NATS, Socket.IO and Phoenix; AGPL-3.0 for Mercure and Soketi.

Redis pub/sub as a backplane#

Redis pub/sub is a channel-based message relay inside Redis. It is not a client-facing server: browsers do not talk to it. Socket.IO, Centrifugo, Laravel Reverb and Phoenix’s Redis adapter use it so that a message published to one app node reaches subscribers connected to the others.

Semantics#

• At-most-once. A message is delivered once if at all; a subscriber that is disconnected or too slow loses it permanently (source: https://redis.io/docs/latest/develop/pubsub/, accessed 2026-10-05).
• Ordered per publisher. Subscribers receive messages in publish order.
• Fire-and-forget. Nothing is stored. Redis Streams add persistence and at-least-once delivery, and are what the Socket.IO Streams adapter and Centrifugo’s history use.
• Sharded pub/sub (Redis 7.0 and later). Shard channels hash to cluster slots and propagate only within a shard, which limits cluster-bus traffic and lets pub/sub scale by adding shards (source: same page).

Licensing#

The license of the server underneath matters when it is a component of your deployment.

(source: https://redis.io/legal/licenses/, accessed 2026-10-05). Centrifugo documents compatibility with Valkey, KeyDB, DragonflyDB and managed Redis services (source: https://centrifugal.dev/docs/server/engines). Valkey 9.1.2 was released 2026-09-01 and Redis 8.10.2 on 2026-09-17 (source: GitHub releases API).

Failure behavior#

If the connection to Redis drops, Socket.IO’s adapter keeps delivering only to clients on the local node (source: https://socket.io/docs/v4/redis-adapter/). Messages published during the gap do not reach other nodes later. A backplane outage therefore shows up as partial delivery rather than an error.

When the backplane is the wrong tool#

Redis pub/sub has no history, so it cannot support recovery by itself, and every node receives every message on the channels it subscribes to. NATS, Kafka and managed pub/sub services are alternatives with their own durability. The Socket.IO adapters list covers Postgres, MongoDB and three cloud buses for teams that do not run Redis.

Socket.IO#

A Node.js realtime library and wire protocol: events, acknowledgements, rooms and namespaces, with automatic reconnection and a polling fallback. Server implementations exist for Node.js and Python (see 1.067 for python-socketio and the client-side details); this survey covers the multi-node story, which is the adapter.

Facts#

Behavior to know#

• Sticky sessions are required when long-polling is enabled across multiple nodes; without them clients get HTTP 400 from a node that does not know the session (source: https://socket.io/docs/v4/redis-adapter/).
• The Redis adapter carries no data persistence and no authentication; anyone who can publish to its channels can inject packets, so Redis must stay on a trusted network.
• If Redis drops, broadcasts reach only clients on the node that sent them.
• The Redis pub/sub adapter and connection state recovery are mutually exclusive; recovery needs the Redis Streams adapter, which has a much smaller footprint (42 stars; 0.3.1, 2026-03-12; source: GitHub API).
• The Redis adapter: last release 8.3.0 on 2024-03-13, 10 open PRs and none merged since 2026-04-05 (source: GitHub). It is stable and quiet rather than abandoned, but it is the part of the stack with the least movement.

Trade-offs#

• Largest community and client matrix of the group; the protocol is custom, so only Socket.IO clients talk to a Socket.IO server.
• The library lives inside the app process, so deploys and connection counts are coupled to the app.
• Server-to-client recovery depends on picking the right adapter.

S2: Technical comparison#

Evidence types, strongest first: measured on one host (the fan-out benchmark), read from the project’s documentation (delivery, recovery, presence, scaling, auth), and read from the repository or registry (versions, licenses, activity). Each figure carries its marker. Where a feature could not be confirmed from a page read during this work, the table says so.

• measurement-plan.md: what was run and what was deferred
• feature-comparison.md: side-by-side tables
• delivery-and-recovery.md: four recovery designs
• fanout-benchmark.md: latency at 1,000 and 4,000 subscribers

Configuration shapes#

Two short examples where the setting is the difference between servers. Both ran in the benchmark harness (measured 2026-10-05, Centrifugo 6.9.7, Mercure v1.0.3).

Centrifugo: channels are closed until opened#

{
  "client": { "allow_anonymous_connect_without_token": true },
  "channel": { "without_namespace": {
      "allow_subscribe_for_client": true,
      "allow_subscribe_for_anonymous": true } },
  "http_api": { "key": "<api key>" }
}

Without the two allow_subscribe_* flags, a client that connected successfully was refused on subscribe with code 103 (permission denied). Production setups use connection JWTs and subscription tokens instead of anonymous access.

Mercure 1.0: legacy tokens need an explicit switch#

mercure {
    publisher_jwt  {env.MERCURE_KEY} HS256
    subscriber_jwt {env.MERCURE_KEY} HS256
    anonymous
    protocol_version_compatibility 8
}

The default 1.0 configuration validates access tokens in a stricter mode with issuer, audience and scope claims. The block above opts into the older behavior: the publisher_jwt and subscriber_jwt directives are refused unless compatibility mode is set, and in compatibility mode the subscribe parameter is topic, where the strict mode rejected it and asked for match.

Socket.IO: recovery is a constructor option plus an adapter choice#

Connection state recovery is enabled with a connectionStateRecovery option carrying maxDisconnectionDuration; it takes effect with the in-memory adapter, the Redis Streams adapter or the MongoDB adapter, and is not supported by the Redis pub/sub adapter (source: https://socket.io/docs/v4/connection-state-recovery).

Delivery guarantees and recovery#

What at-most-once means to a user#

A message is sent once. If the client’s connection is down at that moment, or its buffer is full, or the node restarts, the message is gone. All of the servers in this survey default to this. They differ in what they offer to repair a gap after the fact.

Four recovery designs#

1. Bounded history stream with a position (Centrifugo). Every channel with history enabled keeps a sliding window of recent publications, each with an incrementing offset, under a stream identifier called an epoch. A reconnecting client sends its last epoch and offset. If the epoch matches and all missed offsets are still in the window, the server replays them and reports recovered: true; otherwise it reports recovered: false and the application must reload state from its own store (source: https://centrifugal.dev/docs/server/history_and_recovery). Window size and TTL are per-namespace settings, and the docs describe streams as ephemeral. An optional positioning check disconnects a client whose stream has a gap (disconnect code 3010) so it recovers on reconnect. The same page describes a cache mode that delivers only the latest publication, for dashboards and tickers.

2. Session and packet backup (Socket.IO). The server hands the client a session id and an offset on every packet. Within maxDisconnectionDuration, a reconnecting client regains its socket id, rooms and the packets it missed. It works with the in-memory, Redis Streams and MongoDB adapters, not the Redis pub/sub adapter, and the docs say recovery will not always succeed (source: https://socket.io/docs/v4/connection-state-recovery). Server-to-client at-least-once beyond that is application logic with event ids and stored offsets (source: https://socket.io/docs/v4/delivery-guarantees).

3. Event id replay (Mercure). Each update carries an id; the browser’s EventSource sends the last one in Last-Event-ID on reconnect, and the hub sends everything after it. The spec says hubs may discard older events by policy and subscribers should not assume nothing was lost (source: https://mercure.rocks/spec). This is built into the EventSource API, so the browser does the bookkeeping.

4. Durable stream with acknowledgements (NATS JetStream). Streams persist messages and consumers track a position; unacknowledged messages are redelivered, giving at-least-once. Replay can start from the beginning, a sequence number or a time (source: https://docs.nats.io/nats-concepts/jetstream). A browser can use it through the WebSocket listener, at the price of handling consumers and acknowledgements in client code.

What has no recovery#

Phoenix Channels, Reverb and other Pusher-protocol servers, and Redis pub/sub have no replay. The Phoenix guide says applications needing stronger guarantees must add persistence and recovery themselves (source: https://phoenix.hexdocs.pm/channels.html). The usual pattern for all of these is to store messages in a database and have a reconnecting client fetch what it missed by id or timestamp, which is also the fallback when any of the four recovery designs above reports failure.

Presence delivery#

Presence is a view of who is connected, and it carries the same at-most-once nature. Centrifugo states that join and leave events are delivered at most once (source: https://centrifugal.dev/docs/server/presence), so a client should treat the presence query as the truth and the events as hints. Phoenix Presence replicates state between nodes without a central source and self-heals (source: https://phoenix.hexdocs.pm/presence.html).

Fan-out latency on one host#

Workload#

N subscribers connect to one server on the same machine, using each server’s official client library in Node.js. A backend publisher sends one JSON message of about 100 bytes every 100 ms (10 messages a second) through the server’s publish API: HTTP POST for Centrifugo, Mercure, the Socket.IO control server and the bare ws control; the native TCP client for NATS. Subscribers receive over WebSocket (Centrifugo, Socket.IO, NATS and ws) or SSE (Mercure). Each message carries a monotonic-clock timestamp taken just before the publish call; each subscriber records the difference when its callback fires. Ten warmup messages are excluded. Latency is therefore publish call to client callback, one way, and includes the HTTP publish for four of the five targets.

Subscribers run in four worker threads that share the same monotonic clock. 1,000 subscribers: 100 measured messages per run, three runs per target, alternating target order. 4,000 subscribers: 60 messages per run, two runs. Recipes and raw output are in harness/1-067-2-realtime-broadcast-pubsub/ (run-all.sh, results/n1000.jsonl, results/n4000.jsonl).

Environment#

(measured 2026-10-05) Linux 6.6.87.2-microsoft-standard-WSL2, aarch64, 8 logical CPUs, 11 GB RAM, with other containers running on the host; Node.js v20.20.0; Centrifugo v6.9.7 (memory engine, defaults except permission flags); Socket.IO 4.8.4 server and client with WebSocket transport only and the default in-memory adapter; Mercure hub v1.0.3 in protocol-compatibility mode 8 with BoltDB defaults; NATS server v2.15.0 with a no-TLS WebSocket listener and @nats-io/nats-core 3.4; ws 8.22 as a floor. One machine runs servers, publisher and all subscribers, so they compete for CPU.

Results#

1,000 subscribers, median across 3 runs (measured 2026-10-05; milliseconds):

4,000 subscribers, median across 2 runs (measured 2026-10-05; milliseconds):

How to read it#

• The load generator is most of the number. The bare ws floor is 15 ms at p50 with 1,000 subscribers and 39 ms with 4,000, with no framework in the path. Each worker thread processes its subscribers’ callbacks one after another, so latency grows with subscribers per thread. Differences smaller than the floor’s own run-to-run spread are not evidence of a faster server.
• Run-to-run spread is wide. At 1,000 subscribers the p50 of Centrifugo ranged from 14.5 to 28.5 ms across its three runs, and p99 of Socket.IO from 50 to 65 ms. A first set of runs with every subscriber on a single loopback address gave the same ordering (appendix file n1000_single-ip.jsonl) with some p99 outliers up to 494 ms, which is why subscribers were later spread over four loopback addresses; the host’s ephemeral port range here is only 4,096 ports, which blocked a single-address run at 5,000.
• What the data supports. Centrifugo, Socket.IO and the bare ws floor are indistinguishable at 1,000 subscribers; NATS sits a few milliseconds above; Mercure is about twice as high at 1,000 subscribers (p50 33.8 against 14.4 to 15.7 ms) and about 1.5x at 4,000 (65.6 against 41 to 48 ms). Mercure’s number includes the cost of the SSE client library in Node and Caddy’s HTTP layer, so it describes this stack, not the Mercure protocol.
• Delivery was complete in nine of ten runs at 4,000 subscribers. One Centrifugo run delivered 99.98% of messages. The cause was not isolated: the survey did not capture client or server logs for it. Because all servers default to at-most-once, a skipped message under load is within their contract.

What this does not measure#

Multi-node fan-out through a backplane, history or recovery cost, TLS, a real network, publishers that are browsers, message sizes other than about 100 bytes, rates above 10 messages a second, or Phoenix and Reverb (they need an application to host them). Memory use per connection was not recorded. The Mercure run used its legacy-compatibility configuration, because the default 1.0 token rules could not be satisfied from the documentation within the time available.

Feature comparison#

Sources are the projects’ documentation pages cited in S1, read 2026-10-05. A dash means the feature is not built in.

Delivery, history, presence#

Scaling and transport#

Authentication and authorization#

License and edition line#

Measurement plan#

L2 is the only level that runs in one container with no external service, so it is the cut line. Phoenix and the Pusher-protocol servers are not in L2: Phoenix needs an Elixir application to measure, and Reverb needs a Laravel one. The coverage gap follows from S1’s finding that Phoenix and Reverb are frameworks rather than standalone servers. L3 items are deferred as follow-ups.

L2 does not reach a browser, so there is no floor model; the numbers are measured-local only.

S2 recommendation#

1. Fan-out speed does not separate these servers on one host. Centrifugo, Socket.IO and a bare ws broadcaster are within noise at 1,000 and 4,000 subscribers (measured 2026-10-05, local, aarch64 WSL2). NATS is a few milliseconds above; Mercure is about twice as high at 1,000 subscribers and about 1.5x at 4,000, with its HTTP stack and SSE client in the path and the hub in legacy compatibility mode 8. The numbers describe this stack, not the Mercure protocol. Choose on features and operations.
2. Recovery is the main technical difference. Centrifugo’s history stream with offsets, Socket.IO’s state recovery (on the Streams and MongoDB adapters only), Mercure’s Last-Event-ID replay and NATS JetStream each fix a gap in a different way. Phoenix, Reverb and Redis pub/sub have none.
3. Multi-node is a license question for Mercure and an adapter question for Socket.IO. Centrifugo and NATS do it in open source; Phoenix does it with Erlang distribution; Mercure needs a paid license.
4. Presence differs most between Phoenix (replicated, self-healing) and everything else (a roster you query and reconcile).
5. Protocol decides the client. Only Mercure works with a native browser API and no library for receiving; Pusher-protocol servers reuse Pusher’s clients.

Scaling and backplanes#

How a message published on one node reaches clients connected to another, and what breaks when the link between nodes does.

Connection ceilings#

Documented limits are mostly about the operating system, not the server:

• Laravel documents a default event loop limited to about 1,024 open files, and the ext-uv loop removes that (source: https://laravel.com/docs/12.x/reverb).
• Reverb’s docs also point out that one address has a bounded ephemeral port range (28,231 ports on a typical Linux default), which limits connections from a single client IP behind a proxy.
• On the benchmark host used here the ephemeral port range was 4,096 ports, which capped a single loopback address below 5,000 connections (measured 2026-10-05).

Reading the table#

Redis appears as the shared backplane in four of the six rows. It is also the source of the main failure mode: when it is unreachable, the pub/sub-based paths degrade to per-node delivery without raising an error. Centrifugo’s NATS and PostgreSQL brokers, Mercure’s transports and NATS’s own clustering are the alternatives for teams that do not want Redis, and Socket.IO lists Postgres, MongoDB and three cloud buses.

S3: Personas#

Document merging (shared text editing) is a separate problem layered on top of one of these transports and is out of scope.

S3 recommendation#

One conclusion repeats across all four: every server here can lose a message, so the application database remains the system of record and the real-time server is the delivery layer.

Persona: chat#

Situation#

Rooms or direct conversations, messages that must not silently vanish, users who switch networks and wake laptops, and a need to show who is online or typing.

What matters#

• History and recovery. After a reconnect the client must catch up or know it cannot. Every server here is at-most-once, so the question is the repair path.
• Per-room authorization. A user may join some rooms and not others.
• Two-way traffic. Sending a message and typing indicators.
• Presence at room scale.

Options#

• Centrifugo. A history stream per room, with offset and epoch recovery, a recovered signal that says when to reload from the database, presence and join/leave, and per-namespace permissions. Backend can be any language. The open-source edition scales across nodes with Redis.
• Phoenix Channels. Excellent presence and clustering when the backend is Elixir. Recovery is built by the application: store messages, fetch by id after reconnect.
• Socket.IO. Rooms are first-class and the community is large. For recovery, run the Redis Streams or MongoDB adapter rather than the Redis pub/sub adapter, and keep an application-level fetch for the cases recovery cannot cover. Presence is application code.
• NATS JetStream. Strong durability when the team already runs it; per-room permissions and presence are yours.
• Mercure. One-way, so sending goes through your HTTP API and receiving through SSE. Workable for small chat; presence through the subscriptions API; multi-node needs the paid license.

Verdict#

Centrifugo for a polyglot backend; Phoenix when the stack is Elixir; Socket.IO when the stack is Node and the team accepts storing history in its own database. Whichever is chosen, keep messages in a database and treat server-side history as a cache of recent ones.

Persona: collaborative presence#

Situation#

A shared document, board or form where people want to see who else is here, where their cursors are and what they are selecting. Updates are small, frequent and disposable: a stale cursor position is useless a second later.

What matters#

• A reliable “who is here” list. Joins, leaves and crashed tabs must resolve to a correct roster.
• Cheap ephemeral broadcasts for cursor and selection data, with no need for history.
• Cluster-consistent presence if more than one node serves a room.

Options#

• Phoenix Presence. Built to replicate a roster across nodes without a central store and to self-heal; changes broadcast on PubSub. The strongest built-in answer for an Elixir team.
• Centrifugo. Presence query, presence stats and join/leave events, with per-connection info attached from the token. Join and leave are at-most-once, so clients should poll or re-query the roster occasionally. Presence uses extra server state, so enable it only on namespaces that need it (source: https://centrifugal.dev/docs/server/presence).
• Pusher-protocol servers (Reverb). Presence channels are part of the protocol and expose a member list to clients.
• Socket.IO. No presence service. Apps keep a roster in the server or Redis and update it from connect and disconnect events; listing sockets in a room works across nodes through the adapter.
• Mercure. Subscriptions API publishes subscription events, which can drive a roster but gives no client-to-client path.
• Hosted Supabase Realtime. Offers Broadcast and Presence as a service (vendor: https://supabase.com/docs/guides/realtime); its server is open source (Apache-2.0).

Verdict#

Phoenix Presence if on Elixir; Centrifugo or a Pusher-protocol server otherwise, accepting at-most-once join and leave events and re-querying the roster; Socket.IO when the team already builds on it and is willing to own the roster. Merging concurrent edits to document content is a separate library layered on the same transport.

Persona: live dashboards#

Situation#

Metrics, prices, queue depths or job progress shown to many viewers. Updates are server to client only, a missed tick is replaced by the next one, and the newest value is what matters on reconnect.

What matters#

• Latest-value recovery. A viewer returning from a sleeping laptop should see the current state, not replay of every tick.
• Cheap fan-out to many viewers of the same channel.
• Proxy-friendliness. One-way traffic can ride plain HTTP.

Options#

• Mercure. SSE with the browser’s own EventSource, no client library, and Last-Event-ID resume. Publishing is a plain HTTP POST from the metrics job. Single node on the open-source hub; multiple nodes need a Self-Hosted license. AGPL-3.0 applies to the hub.
• Centrifugo. Cache recovery mode delivers only the most recent publication on reconnect, which matches the need exactly. It also offers unidirectional SSE and WebSocket transports that work with native browser APIs.
• NATS. Subjects per metric and JetStream key-value for the current value; the browser needs the NATS client and permission setup. A fit if NATS already carries the metrics.
• Socket.IO. Works, with rooms per dashboard; replay is not needed here, so the adapter choice matters only for multi-node scaling.
• Redis pub/sub as the only layer. Not reachable from browsers.

Verdict#

Mercure for a single-node, minimal-client setup; Centrifugo when more than one node is needed without a license fee, or when the latest-value recovery is required; NATS when it is already the metrics bus. The fan-out numbers in the benchmark page show all four deliver within tens of milliseconds at 1,000 subscribers on one host, which is far below dashboard refresh needs.

Persona: notifications#

Situation#

In-app alerts to individual users: a comment reply, a finished export, a payment result. Each message is for one user (or a small group), must not leak to anyone else, and matters even if the user is offline when it fires.

What matters#

• Per-user channels with enforced privacy.
• A fallback for offline users. Real-time servers deliver to connected clients; a user who is away needs the notification stored and shown on return, or sent through email or mobile push.
• Many mostly idle connections, with low traffic per connection.

Options#

• Centrifugo. User-limited channels (the # boundary reserves a channel to a named user) and connection JWTs make per-user delivery a configuration matter (source: https://centrifugal.dev/docs/server/channels). A push notification API for device tokens exists in the paid PRO edition.
• Mercure. Private updates are matched against the subscriber’s token, so a per-user topic stays private; SSE reconnects with Last-Event-ID replay recent ones.
• Laravel Reverb or any Pusher-protocol server. Private channels with a signed auth endpoint, a natural fit if the app is on Laravel or already uses Pusher clients. No replay.
• Phoenix Channels. A per-user topic joined after authentication; recovery is the app’s job.
• Socket.IO. One room per user id, joined in handshake middleware.
• Hosted Pusher or Ably. Per-connection pricing makes a large number of idle connections the cost driver; compare against machine cost.

Verdict#

The deciding step is storing notifications in the application database and using the real-time server only to nudge connected clients. With that in place, any server here works; choose by the language and protocol the team already runs. Mobile and offline delivery is outside these servers and covered in 1.119.2.

S4: Viability#

Signals read on 2026-10-05: latest release, last push, the stall test (open PRs against PRs merged since 2026-04-05), license, and what the license or edition does to a self-hosting team over time. Source for every count is the GitHub REST and search APIs unless noted.

Licenses and editions#

What AGPL changes in practice#

AGPL-3.0 applies to the program covered by it. A hub run unmodified beside an application, and reached only over the network, does not extend the license to the application. A team that patches the hub and exposes the patched version to users owes those users the patch source. Legal review of a specific deployment is outside this survey.

Editions that change what you can do#

Mercure’s free hub is limited to one node; the license is the high-availability switch. Centrifugo’s open-source edition scales across nodes with Redis, so its paid PRO line sits at operations and push features. A requirement list that includes multi-node, push notifications and rate limiting reads very differently across the two.

Portability and exit#

How hard it is to leave each option, in terms of the things the application is coupled to.

Practice#

Put publishing behind one function in the backend and keep subscription setup in one client module. That confines a migration to two files. Where recovery matters, keep message storage in the application database so that no server’s history format becomes the only copy.

S4 recommendation#

• Safest long-term bets by activity and license: NATS (Apache-2.0, 415 merges in six months), Centrifugo (Apache-2.0, 117), Phoenix (MIT, 126).
• Take care with: Soketi (stalled; move to Reverb or Centrifugo), the Socket.IO Redis Streams adapter (small and pre-1.0 yet required for recovery), Mercure’s AGPL-3.0 and paid multi-node line.
• Keep the transport behind your own thin publishing function. Backends publish through an HTTP call in Centrifugo, Mercure, Reverb and Soketi alike; wrapping that call in one module keeps a later switch to a different server contained to that module and the client SDK.
• Standards help portability. Mercure is a published protocol with a spec, Pusher’s protocol has two independent open implementations, and SSE and WebSocket are browser standards. Socket.IO, Phoenix, Centrifugo and NATS clients are tied to their servers.
• WebTransport is now in all three major engines (Safari 26.4, March 2026 per one secondary report and caniuse.com/webtransport; Chrome since 97; Firefox since 114; source: https://webrtc.ventures/2026/04/webtransport-is-now-baseline-what-it-means-for-real-time-media/, accessed 2026-10-05), but Centrifugo still labels its server support experimental and not recommended for production (source: https://centrifugal.dev/docs/transports/webtransport). Plan on WebSocket and SSE.

Viability by option#

Patterns#

• License changes are the main strategic risk in the backplane. The Redis license moved from BSD to source-available to a tri-license that includes AGPL in the span of 2024 to 2025 (source: https://redis.io/legal/licenses/). A team that wants a permissive license underneath can use Valkey, which Centrifugo lists as compatible.
• Open-source ceilings. Mercure’s free hub is single-node; Centrifugo’s PRO adds operational and push features, not core multi-node. Check which side of the line a requirement sits on before committing.
• Components age differently from their servers. Socket.IO is active while the Redis adapter’s last release is from March 2024. Adapters are where durability questions land, so their repositories deserve their own check.