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

• Message ordering: PubNub only orders messages by when its servers receive them, so rapid publishes can end up out of send order. Ably keeps send order on a realtime connection. This matters most for workloads like AI token streams.

• Exactly-once delivery: PubNub leaves it to you to build it. Ably provides it natively, as long as a client reconnects within two minutes. This is where a wrong choice costs your team the most engineering time.

• Automatic reconnection: PubNub caps catch-up at 100 messages or 16 minutes, whichever comes first. Ably caps it at two minutes, with no fixed message count, so a burst during a short outage doesn't overflow it.

• Message size and throughput: PubNub's standard limit is 32 KiB, raised only on request. Ably allows 64 KiB on Free and Standard and 256 KiB on Pro, and its publish rate limit rises with your plan. 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 each message a timetoken when its servers receive it, and orders the channel by timetoken. Its docs note this "can differ from when the client sent it", so rapid publishes sent as separate HTTP requests can be delivered in the wrong order. 

Ably: guarantees that messages published on a realtime connection reach subscribers in the order they were sent, using an incrementing serial on each connection. 

Ordering is the first place the platforms diverge. Exactly-once delivery is the second.

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 retried publishes automatically within a two-minute window, using message IDs the SDK assigns or IDs you supply. Combined with connection recovery, each message is delivered exactly once, as long as the client reconnects within two minutes.

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

This 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. A reconnect within two minutes replays everything the client missed, with no fixed message count.

When it comes to filling the gap after the reconnection 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, the SDK tells you when a resume fails, and you fetch the gap from the History API using untilAttach, so it joins the live stream cleanly. Persisted history must be enabled on the channel.

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

PubNub: has a standard 32 KiB message limit, raised only on request. 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, 256 KiB on Pro, and custom limits on 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 rate limit scales by plan: 500 messages per second on Free, up to unlimited on Enterprise.

On message size, Ably's default tier already allows twice PubNub's standard limit, so there's less splitting code to write from day one. On throughput, PubNub has no plan cap but recommends a per-channel rate, while Ably's limit rises with your plan.

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 two-minute window isn't capped by message count, so a burst during a short outage is replayed rather than dropped. If the outage runs longer than two minutes, the client fetches what it missed from the History API.

Take a trading dashboard streaming price ticks.

• On PubNub, a flaky connection during a volatile session can outrun the buffer, and the chart then drops ticks without flagging them as missing. Ticks published in rapid succession can also land out of order, and a retried publish can create a duplicate tick.

• On Ably, the same session would only miss ticks if the connection stayed down for more than two minutes, and those ticks could still be fetched from History. Ticks arrive in the order they were sent, and a retried publish is deduplicated automatically.

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. Tokens published in quick succession can arrive out of order, a dropped connection can lose part of the answer once the buffer is exceeded, and a retried tool call can duplicate a visible chunk of text.

• On Ably, the higher message-size ceiling makes splitting a long response far less likely. Tokens keep their send order, a dropped connection recovers automatically within two minutes, and a retried tool call is deduplicated within the same window.

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: a server-assigned timetoken on every message, and a generous free tier for occasional-use cases. What it leaves for your team to build is send-order preservation, exactly-once delivery, and the pagination that comes with any catch-up beyond its buffer. Ably handles ordering, deduplication, and time-bounded replay by default, as properties of the platform rather than code you write.

The question to ask: can your application tolerate an occasional out-of-order message, a duplicate side effect, or a rare gap in delivery during a long outage? If a reordered price tick or a double-booked appointment is a shrug rather than an incident, PubNub's primitives are a reasonable starting point. If those are correctness bugs your team would rather not build a 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.

Not exactly. On Ably, all subscribers connected to the same region see the same order, and history uses a separate canonical global order across regions. A reconnect backlog uses the regional order, so it matches what the client already received. PubNub's docs say live arrival order can differ from timetoken order and between subscribers, while history follows timetoken order.

PubNub Support can raise the default buffer (100 messages, 16 minutes) per keyset, for example, to 300 or 500 messages. But 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.

On PubNub, Message Persistence retention runs from 1 or 7 days on Free, up to 6 months on Starter, and 1 year or unlimited on Pro. On Ably, History API retention runs from 1 day on Free, through 30 days on Standard, to 1 year on Pro, with custom retention on Enterprise.

No. 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 standard limit 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, and infrequent publishing makes reordering less likely too. 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.