Ably vs PubNub: message ordering, delivery, and reconnection compared

• Message ordering: equivalent on both platforms. Not a differentiator, so it's not a reason to choose either one.

• Exactly-once delivery: PubNub leaves it to you to build. Ably provides it natively. This is where the platforms diverge most, and where a wrong choice costs your team the most engineering time.

• Automatic reconnection: PubNub caps catch-up by both count and time (100 messages or 16 minutes, whichever comes first). Ably caps it by time only (two minutes), with no message-count ceiling. A busy channel can outrun PubNub's cap during a long outage. Ably's cap can't be outrun by volume, only by time.

• Message size and throughput: PubNub tops out at 32 KiB. Ably scales up to 256 KiB, with throughput up to unlimited on Enterprise. Bigger limits mean fewer messages to split, batch, or rate-limit in your own code, at the cost of a higher-tier plan.

The four properties below are where message reordering, duplicate delivery, and reconnection gaps actually originate, and where Ably and PubNub differ enough to change how much your team has to build.

PubNub: assigns every message a monotonically increasing timetoken, guaranteeing order per channel.

Ably: assigns a serial that plays the same role, guaranteeing order per publisher per channel.

Neither guarantees order across different publishers on the same channel. If one publisher's message depends on another's, your application has to coordinate that ordering itself.

On ordering alone, the platforms are equivalent, and the real differences show up in exactly-once delivery and reconnection.

PubNub: has no server-side deduplication, so a retried publish always creates a second, distinct message. Exactly-once processing is something you build yourself, typically with an idempotency key.

Ably: deduplicates natively, using a unique message identifier assigned automatically to suppress a duplicate publish, with no application code required.

PubNub offers two partial workarounds: some SDKs add subscribe-side dedup for exact repeats, and there is an opt-in qos=1 REST parameter that confirms a publish reached every connected subscriber before returning. But neither solution deduplicates a retried publish.

This is the sharpest functional difference between the platforms, and it matters most for anything transactional (a booking, a payment, or a chat message) where a duplicate is a correctness bug, not a cosmetic one.

PubNub: bounds automatic catch-up on reconnect to a 100-message, 16-minute buffer, whichever limit hits first. Once that limit is reached, PubNub drops older messages, oldest first.

Ably: bounds replay by time only. Any reconnect within two minutes replays everything missed, regardless of message count.

Filling the gap after the window closes: once either window closes, both platforms fall back to a history API, but the amount of work involved is different.

• On PubNub, you build your own fetch logic against the Message Persistence API. That means detecting that the buffer boundary was exceeded, then paginating through the gap yourself in batches of up to 100 messages per call.

• On Ably, reconnecting after the two-minute window still triggers a fallback, but it's always a single History API call, with no separate boundary-detection logic to write.

None of this depends on how big any single message is. Message size and throughput are a separate constraint entirely.

PubNub: caps messages at 32 KiB. That's enough for a typical chat message or a small JSON event. It's tight for something like a full document diff or a batch of sensor readings, since those need to be split across multiple messages and reassembled on the other end.

It doesn't hard-throttle publish rate for keys in good standing, though it recommends ten to 15 messages per second per channel as a best practice. Publish faster than that, and a slow subscriber's buffer can start to overflow.

Ably: allows messages up to 64 KiB on Free and Standard, rising to 256 KiB on Pro and Enterprise, per Ably's package limits. That's usually enough for the same document diff or sensor batch to fit in one message.

Its publish throughput scales by plan too: 500 messages per second on Free, up to unlimited on Enterprise. Compared to PubNub's ten-to-15-messages-per-second guidance, a busy channel on Ably is less likely to need client-side rate-limiting to stay within plan.

The tradeoff isn't symmetric between the two limits.

On message size, Ably's default tier already gives you more for free, so there's less code to write from day one. On throughput, paying for a higher Ably tier buys real headroom that PubNub doesn't offer at any price, in exchange for writing less client-side rate-limiting code.

Ordering and exactly-once guarantees apply the same way regardless of message size: what changes is only how many messages a given payload needs, not whether it arrives in order or exactly once.

For PubNub, the 100-message, 16-minute reconnect buffer is the constraint that actually bites in production. When disconnects are short and infrequent, it absorbs them, and nothing goes wrong. The buffer overflows when an outage runs long, or when a channel publishes more messages than it can hold during a shorter one.

When that happens, PubNub drops the oldest messages. The application then has to detect the overflow itself, switch to manual history reconstruction, and build its own idempotency layer if duplicates matter too.

Ably's parallel scenario looks different, because its two-minute window has no message-count ceiling, so the same volume of messages during an outage never causes a silent overflow. The only way to exceed it is for the outage itself to run longer than two minutes, at which point Ably falls back to the History API rather than losing anything.

Take a trading dashboard streaming price ticks.

• On PubNub, a flaky connection during a volatile session can outrun the 16-minute buffer, and the chart then silently drops ticks without ever flagging them as missing. A retried publish during that same session can just as easily create a duplicate tick instead.

• On Ably, the same volatile session would only lose ticks if the connection stayed down for more than two minutes. A retried publish would never duplicate, either, since deduplication is automatic.

AI token streaming runs into the same failure modes from a different angle.

• On PubNub, a long response can approach the 32 KiB message-size limit and need splitting across multiple messages. A dropped connection mid-generation can lose part of the answer once the buffer is exceeded. A retried tool call, with no platform-level dedup, can duplicate a visible chunk of text.

• On Ably, the higher message-size ceiling makes splitting a long response far less likely. A dropped connection recovers automatically within the two-minute window. A retried tool call is deduplicated natively, so it can't create a duplicate chunk of text.

Ably AI Transport packages guaranteed ordering, exactly-once delivery, and session recovery into one layer for that second case specifically. See the AI applications deep dive for the full comparison.

PubNub gives you solid primitives: guaranteed per-channel ordering, and a generous free tier for occasional-use cases. What it leaves for your team to build is exactly-once delivery and the pagination that comes with any catch-up beyond its buffer. Ably treats those same primitives as already handled by default: ordering, deduplication, and time-bounded replay are properties of the platform, not code you write.

The question to ask: can your application tolerate an occasional duplicate side effect, or a rare gap in delivery during a long outage? If a duplicated price tick or a double-booked appointment is a shrug rather than an incident, PubNub's primitives are a reasonable starting point. If a duplicate is a correctness bug that your team would rather not build a dedup layer to catch, Ably's guarantees are built for exactly that.

Start building on Ably for free, or talk to an engineer about your delivery requirements.

Within a single region, yes: both guarantee a strict per-channel sequence that every subscriber connected there sees identically. Ably's architecture also tracks a separate "canonical global order" across all regions, used for consistent history results. PubNub's docs don't describe an equivalent global-ordering concept. A reconnect backlog on Ably specifically uses the local, per-region order rather than the canonical one, so it matches what a client already received. If your application depends on strict cross-region ordering beyond what's described here, check directly with PubNub support, since this isn't confirmed in their public docs.

PubNub's default buffer (100 messages, 16 minutes) can be raised by contacting PubNub support, though it stays a set capacity rather than becoming unbounded. Ably's two-minute connection-state window isn't adjustable: Ably's package limits confirm it holds at two minutes on every plan, from Free to Enterprise. Anything beyond either window has to go through a history API instead, since neither buffer extends indefinitely.

On PubNub, Message Persistence retention runs from seven days on Free up to unlimited on paid plans, depending on what you configure. On Ably, History API retention runs from one day on Free, through 30 days on Standard, up to one year on Pro and Enterprise. Ably doesn't offer an unlimited tier at any plan level. If you need to reach back further than a year for audit or compliance reasons, PubNub's unlimited option is the only one of the two that supports it.

No. Both guarantees apply per message, regardless of size: neither platform changes how it orders or deduplicates messages based on payload size. What size changes is how often one logical payload needs multiple messages to carry it. PubNub's 32 KiB ceiling makes chunking more likely for larger payloads, and each chunk still has to be reassembled in order downstream. Ably's higher ceiling reduces how often that reassembly work is needed at all.

The message-count side, yes: a low-volume channel is less likely to hit 100 messages during a disconnect. But the 16-minute clock runs regardless of volume, so a long outage on an infrequent channel can still exceed the buffer on time alone. Ably's two-minute window is time-only to begin with, so publish volume doesn't affect it either way.