← back to blog

Problems with PubNub: A Deep Dive into Chat System Challenges

Project Requirements

In our client's project, we were tasked with developing a comprehensive chat module. The requirements included one-to-one, group, and community chat, where all users could participate without strict limitations on joining specific chat channels.

Architecture Choices

To meet these requirements, we opted for PubNub as our messaging infrastructure. We structured the system to assign a single PubNub channel for each one-to-one chat, a single channel for each group chat, and a separate channel for community discussion groups. We also leaned on PubNub channel groups to simplify subscription management for each user.

Problem 1 — Adding Channels to Channel Groups

A significant hurdle was the limit on how many channels can live in a PubNub channel group. The ceiling is 2000 channels (PubNub officials recommend a more conservative 1500) — and going past it leads to unpredictable outcomes.

The silent failure: exceed the limit and the system may not throw an error even though it reports success. The add can fail silently, leaving you unsure whether the channel actually landed in the group. To be certain, you have to make a second SDK call to list the registered channels — an extra verification step that adds complexity and hints at deeper reliability gaps.

Problem 2 — Device Token Registration for Push

PubNub offers built-in push notifications, which looked promising. You feed your cloud-messaging credentials and iOS push details into the PubNub dashboard, and from then on PubNub handles delivery. To turn on notifications for a channel, you supply the device tokens to that channel so any incoming message triggers a push.

The pain shows up with heavy users. Someone active across one-to-one, group and community chats ends up tied to many channels — and you must register each channel against each of the user's tokens separately. There's no way to register multiple channels (or a whole channel group) in one shot. The result is a flood of backend calls to PubNub, dragging down performance and efficiency.

Problem 3 — Channel Manipulation in the Token Flow

Managing already-registered channels is just as awkward. Say you've attached 2000 channels to a device token and now want to mute or remove some. You can't drop them directly — you first fetch which channels are on the token, then make another call to remove the unwanted ones.

The kicker: when you fetch the channels on a token, you only get the first 500. No pagination, no way to page through the rest — just the first 500, plain and simple.

Problem 4 — PubNub API Constraints

There's also a 32KB payload ceiling on PubNub API operations, which bites when sending larger messages or doing channel manipulations and limits how far the chat system can scale. On top of that, concurrent PubNub calls started throwing errors — adding complexity and chipping away at reliability.

Conclusion

PubNub can be plenty for smaller-scale use cases, but it falls short when you're building a robust, scalable chat system. Limits around channel management, push registration and API payloads all get in the way at scale, and better documentation and logging would go a long way toward a smoother developer experience. As we work around these constraints, we're evaluating alternatives better matched to the size and complexity of what we're building.

Thanks for reading! Building something chat-heavy and wrestling with the same walls? Ping me — I'd love to compare notes.
#chat#pubnub#tech