Ably vs PubNub deep dive: WebSocket delivery, ordering guarantees, integrations, and pricing

Does PubNub guarantee message ordering? No. PubNub's own documentation states that messages are typically kept in order when publishers send slower than consumers can receive, but strict ordering is not guaranteed. Applications that depend on it add a sequence field and sort client-side. Ably guarantees ordered delivery for realtime library subscribers, with two exceptions: REST publishing at high rates, and a rare server-recycling edge case during reconnection.

What happens when a PubNub client disconnects and reconnects? PubNub's connection management documentation states that the autoreconnect buffer holds up to 100 messages for up to 20 minutes, with older messages discarded first when the limit is exceeded. It works well for low-volume channels where gaps are acceptable. Ably automatically replays missed messages in order for reconnections within two minutes, with no application logic required. Beyond two minutes, both platforms require the application to query message history to catch up.

Does PubNub use WebSockets? Not natively. PubNub's data transport documentation describes HTTP as its core transport, with the SDK adapting to the most efficient available protocol per environment. A WebSocket-compatible interface is provided in some SDKs. Ably uses native WebSockets as its primary transport, with SSE, MQTT, and HTTP long-polling as fallbacks. This matters in environments where protocol behavior and overhead are significant, including constrained devices and AI streaming clients.

Does PubNub support idempotent publishing? No. Deduplication on retry is the application's responsibility. Ably suppresses duplicate publishes at the platform level using message identifiers, enabled by default in current SDKs. The detection window is two minutes: a publisher retrying an unacknowledged message after more than two minutes would not have the duplicate suppressed.

How do Ably and PubNub pricing models differ? PubNub prices on monthly active users, which is predictable for steady user bases but can become expensive when a small number of users generate disproportionate traffic. Ably offers usage-based pricing tied to messages, channels, and connection minutes, or MAU-based pricing. Neither model is universally cheaper: evaluate against your actual traffic shape, including reconnect frequency and peak load.

Can I replay missed messages on PubNub without building my own storage? Partially. PubNub's Message Persistence documentation states it is enabled by default on newly created keysets and stores messages for a configurable retention period. Retrieving them after a disconnect requires the application to query the history API, handle the overlap window, and deduplicate. Ably persists channel history by default and replays it automatically on reconnection within the two-minute recovery window, with no application-side query required.

The right question is not "what does it support?" but "how does it behave when things go wrong?"

• Continuity: what happens to messages sent while a client is offline?

• Ordering: do subscribers see events in the same order, including after reconnect?

• History and replay: can clients retrieve what they missed without building their own storage?

• Reliability under failure: when networks or regions degrade, does behavior stay predictable?

• Availability at scale: do delivery guarantees hold during peak load and failover?

• Integrations and protocols: does it support the protocols and integrations you need?

• Ops transparency: are failure modes, SLAs, and controls explicit and verifiable?

• Pricing fit: how does pricing behave under spikes and reconnects?

• Product layers: do you get productized building blocks, or only primitives?

Both Ably and PubNub are designed for low-latency realtime messaging at global scale. PubNub runs on 15 or more points of presence globally and advertises sub-50ms delivery in most regions. That is a genuine strength for latency-sensitive use cases like gaming and IoT. Ably reports 6.5ms message delivery latency running across 15 physical datacenters with 700+ edge locations globally through AWS CloudFront.

Raw latency numbers matter less than consistency under load. Both platforms are fast on a stable connection. The more relevant question for most production systems is whether latency stays predictable during reconnect storms, traffic spikes, and partial failures. This includes the kind produced by large numbers of AI clients resuming sessions simultaneously.

PubNub's message publishing documentation states that messages are typically kept in order when publishers send slower than consumers can receive. For applications requiring strict ordering, the recommended approach is to add a sequence field to the message payload and sort client-side. That logic sits in your code.

Ably guarantees ordered delivery to realtime library subscribers on a channel. Two conditions apply. First: publishing over REST at high rates as separate HTTP requests can break ordering, because a later request can arrive before an earlier one. Second: if the server maintaining a disconnected client's connection state is terminated at the exact moment of recovery, messages can arrive out of order. Ably's own documentation describes this as plausible but unlikely. For realtime library publishers on stable connections, the guarantee holds.

The recommended approach for applications that cannot tolerate duplicates on PubNub is to add a sequence field to the message payload and handle deduplication client-side. This is a well-understood pattern, but the work lands in your code.

Ably supports idempotent publishing through message identifiers, enabled by default in all current SDKs. The platform suppresses duplicate publishes. The detection window is two minutes: a publisher retrying an unacknowledged message after more than two minutes would not have the duplicate suppressed. For retries within normal operational timeframes, the guarantee holds.

A 50-user chat room. The network degrades for 30 seconds, and clients reconnect at roughly the same time. On a best-effort delivery model, the reconnect storm can produce messages out of order, duplicated retries, and gaps that differ across clients. Each client may see a different view of what happened. The application must reconcile these differences.

With guaranteed ordering and idempotent publishing, all clients resume from the same offset in the same sequence. No reconciliation logic is required. Every client converges on the same view of the channel.

The same properties hold for an AI assistant streaming a response to multiple subscribers. Every surface sees the same token sequence, in order, with no gaps on reconnect.

An AI agent is mid-task when the connection drops briefly. The agent retries a tool call (creating a calendar event, submitting a form, or calling an external API) before the acknowledgment arrives. On PubNub, all three retries may be delivered. The downstream system receives three calls and must deduplicate. On Ably, the idempotent publisher ID suppresses the duplicates at the platform level. The downstream system receives one.

For read-only operations like search or retrieval, this rarely matters. For any tool call with a side effect, a triple delivery is a bug and a trust failure. The user asked the agent to do something once.

A monitoring dashboard publishes 50 metric updates per second. A client reconnects after 90 seconds offline. On PubNub, those updates are gone. The dashboard either shows stale data or triggers a full re-fetch from the source system.

On Ably, the client is within the two-minute connection recovery window. It resumes from its last confirmed offset and receives the missed updates in order without any history query. If the disconnection had exceeded two minutes, Ably falls back to the history API. Messages still arrive in order, but the client must initiate the query.

In either case, the platform tells the client which recovery path applied. PubNub has no equivalent notification: the application must assume messages were lost and decide how to recover.

PubNub's connection management documentation states that the autoreconnect buffer holds up to 100 messages for up to 20 minutes. If more than 100 messages arrive during the disconnection, the oldest are discarded first. It works well for low-volume channels where gaps are acceptable.

Ably maintains connection state for up to two minutes after a client disconnects. If the client reconnects within that window, it resumes from its last confirmed position and receives missed messages in order without any application-side handling. If the disconnection exceeds two minutes, Ably drops connection state and falls back to history-based catch-up via the history API. Either way, the client receives confirmation of which recovery path applied, so the application can respond predictably.

The distinction with PubNub is not whether reconnects are handled. It is whether the platform closes the gap automatically within its recovery window, or whether the application always owns that logic. For AI streaming use cases, this distinction is load-bearing: a user who switches devices or refreshes mid-response needs the session to survive, not restart.

Both platforms run globally distributed infrastructure and publish 99.999% uptime SLAs. The difference is how explicitly behavior under failure is defined, and how much of the integrity work sits with the platform versus the application.

Ably runs in 15 physical datacenters, each able to operate independently. It scales system components automatically and replaces unhealthy services and instances. It routes clients away from failing regions, including deliberately disabling a site during an incident to keep service stable. Delivery guarantees continue to hold during regional failover.

PubNub provides availability through a globally distributed network with failover. During recovery, however, maintaining ordering and catch-up behavior sits more with the application than the platform.

PubNub offers broad SDK coverage and a managed serverless environment through PubNub Functions. This suits teams that want business logic to run alongside messages without external dependencies. PubNub's data transport documentation describes HTTP as its core transport, with the SDK adapting to the most efficient available protocol per environment.

Ably supports native WebSocket, SSE, MQTT, and HTTP long-polling. It integrates natively with Kafka, Kinesis, SQS, AMQP, and Pulsar, and supports running alongside PubNub during migration. Teams building on existing event pipelines, or needing MQTT for constrained IoT or AI edge devices, typically find Ably the easier fit.

If you are already on PubNub, migration does not require a client code rewrite. Ably provides a PubNub protocol adapter that handles all translation in the background and requires only an API key change. The adapter introduces some latency compared to using an Ably SDK natively. Some Ably advantages are only available once you transition to Ably's own SDKs. Migration can be done progressively, with both platforms running in parallel during the transition.

PubNub provides messaging primitives and a set of product layers built on top:

• PubNub Pub/Sub: core publish/subscribe messaging across channels

• PubNub Functions: serverless edge compute that runs custom code as part of the message flow, without an external service

• PubNub Chat SDK: purpose-built chat APIs covering messages, presence, typing indicators, and message persistence

Ably provides the same low-level pub/sub APIs and also ships productized layers built on the same foundations of continuity, ordered delivery, replay, and presence:

• Ably AI Transport: applies these same delivery and continuity guarantees to agent-to-UI streaming, so dropped connections and device switches do not reset the session or lose the response mid-stream

• Ably Chat: rooms, typing indicators, presence, history, and message reactions

• Ably LiveObjects: shared realtime state without custom sync logic

• Ably Spaces: lightweight collaboration awareness (cursors, avatar stacks, component locking)

• Ably LiveSync: streams Postgres changes into realtime channels

The practical question is how much of the product experience you want to build yourself versus what you want to ship directly.

PubNub's MAU-based pricing is predictable when usage maps cleanly to active users. It becomes less intuitive when a small number of power users generate disproportionate traffic, or when reconnect storms inflate transaction counts.

Ably offers two models. Per-minute pricing suits spiky or system-driven workloads where user count stays flat but message volume varies. MAU pricing suits products where engagement is steady and per-user costs are easier to model. Both models are available on the same package tiers.

PubNub is a good fit when:

• Realtime updates are advisory and gaps or reordering are acceptable to the application

• Your application already reconciles state from another source of truth

• You want business logic to run alongside messages without external dependencies. Custom code runs at the edge as part of the message flow, not in a separate service.

• You are building on platforms where PubNub's SDK breadth is an advantage, particularly embedded, IoT, or constrained environments where its HTTP-based transport fits better than WebSocket

Ably is a better fit when:

• Message ordering must hold after reconnect, not just during a stable session

• Retries cannot produce duplicate state and idempotent publishing needs to be handled at the infrastructure level rather than in application code

• Clients reconnect frequently and must resume without gaps or manual catch-up logic

• You need to integrate with existing Kafka, Kinesis, or queue infrastructure without a custom adapter

• You are shipping chat, collaboration, or AI streaming features and want the choice of productized building blocks or assembling primitives

• You are building AI-powered features where agents stream responses to a UI and session continuity, token ordering, and reconnect behavior must be handled at the infrastructure level rather than in application code

PubNub gives you the tools to build delivery guarantees in your application. Ably builds them into the platform. Neither approach is wrong: the question is how much of that work you want to own and maintain.

If your team is comfortable owning sequencing, deduplication, and catch-up logic, PubNub's model is flexible and capable. If you want the platform to handle those guarantees, Ably's model reduces that engineering surface significantly. This includes AI workloads, where the same failure modes that affect chat messages apply equally to token streams and agent sessions.