PubNub vs. WebSocket: Pros, cons, and key differences

PubNub is a realtime PaaS built around the Publish/Subscribe design pattern. Using it, engineering teams can rapidly build realtime functionality such as chat, multiplayer collaboration, and realtime dashboards. Distributing data using PubNub relies on its global network, which they claim delivers low latency, high reliability, and scalability no matter where end users are located.

On top of the Pub/Sub model, PubNub offers additional features designed to support specific use cases, such as transforming message contents, authentication, managing user presence, and more.

• Pub/Sub messaging: As a developer working with PubNub, you set up channels that client-side applications subscribe to. That could be one-to-one (such as a private chat between two individuals) or one-to-many (such as broadcasting financial data to subscribers). Messages can be text or binary files up to 5 MB.

• User presence: Track and distribute presence status for connected clients. That’s useful for chat applications, multiplayer games, and pretty much any collaborative realtime environment..

• Push notifications: Alert end users through native iOS and Android push notifications.

• Serverless functions: Transform, filter, and reroute data as it passes through the PubNub platform.

• Event triggers: Send messages to third-party systems for further processing, based on pre-defined criteria.

• Message history and persistence: Store messages for later delivery when a subscriber is unavailable.

• Authentication and encryption: Ensure data is available only to the right subscribers.

• Fully managed global infrastructure: PubNub operates 15 locations across the globe, which should reduce latency for clients further away from your primary cloud regions.

• Strong uptime: PubNub boasts 99.999% uptime for its realtime PaaS.

• Security and compliance: The platform complies with standards such as SOC2, HIPAA, and ISO 27001.

• Faster time to market than self-build: Working with a realtime PaaS is more cost effective and reliable than building an in-house solution.

• Quality of service is limited: PubNub doesn’t guarantee message delivery, ordering, or predictable results (idempotency). To get those results, you’ll need to build additional application logic.

• Performance is below the industry best: PubNub is built on older technology (long polling) that suffers from higher latencies than alternatives such as WebSocket. PubNub promises latencies below 250ms, which is likely to be noticeable by end users.

• Inefficient message delivery: PubNub doesn’t use delta compression. That means that when it transmits a message stream, it sends the entire payload each time rather than only the differences since the last transmission. That can quickly escalate and it reduces PubNub’s ability to deliver at low latencies.

• Poor recovery from errors: PubNub’s message can handle only 100 messages by default. That means that when the system can’t reach a client, anything over 100 messages will be dropped.

WebSocket is both a protocol and an API for communication between a client and a server. So, the main difference compared to PubNub is that WebSocket is not a realtime PaaS. Instead, it gives you the tools to build event-driven, low latency data streaming for your realtime applications but not the infrastructure. 

However, there are technical differences, too. PubNub relies on what could be considered as a technological hack, specifically HTTP long polling, to transport messages between its platform and end clients. WebSocket has been designed from the ground up to replace workarounds, such as long polling, with a dedicated way to enable realtime communication. Despite the technical differences, WebSocket can serve similar use cases to PubNub. For example, chat, data broadcast, and multiplayer collaboration.

• Bidirectional communication: WebSocket is designed for two-way communication between client and server, which makes it more useful for realtime collaboration use cases than alternatives such as Server-Sent Events.

• Persistent connections: Some protocols need to open a new connection for each message or every few minutes, when the previous connection times out. WebSocket keeps connections open for as long as they’re needed, which reduces overhead and latency. Combined with bidirectional communication, that enables especially time-sensitive applications such as gaming and multiplayer collaborative document editing.

• Both a protocol and an API: WebSocket both defines how messages move between client and server and provides a common API that is implemented in browsers, mobile platforms, and elsewhere.

• Efficient data transfer: Older HTTP-based solutions, such as long polling, rely on repeatedly opening HTTP connections with all the overhead that involves.  As WebSocket works with persistent connections, it requires less bandwidth, involves less latency, and puts lower load on the machines at either end.

• Available almost everywhere: As a mature protocol, WebSocket is available in all major browsers, mobile platforms, and in libraries for just about every programming language.

• Application flexibility: WebSocket is concerned only with delivering messages between two points. It doesn’t impose any particular application or use case constraints.

• Not ideal for audio and video: WebSocket works best with text and smaller snippets of binary data. It isn’t optimized for streaming audio and video. This is also true of PubNub, which recommends using a third-party hosted service to stream video and audio.

• Connections don’t recover automatically: If there’s a break in a WebSocket connection, there needs to be additional code somewhere in the infrastructure to take care of reestablishing that connection and resending any messages that were missed during the downtime.

• Connections are stateful: One consequence of persistent connections is that those connections are stateful, meaning that it’s harder to scale WebSocket out across a cluster of servers.

WebSocket’s widespread support, efficiency, and reliability make it a common choice for teams building realtime platforms. As PubNub is a realtime PaaS, you might expect that it would support WebSocket but one potential disadvantage of PubNub is that it does not support WebSocket. Instead, it relies on an older workaround called HTTP Long Polling.

The main difference between PubNub and WebSocket is that PubNub is a PaaS that engineering teams use to outsource the realtime aspects of the products they build. WebSocket, on the other hand, is a protocol that provides a common standard for communicating between clients and servers that requires either in-house engineering or a different realtime PaaS.

Let’s take a look at how the two compare.

As a hosted service, PubNub provides the infrastructure to deliver realtime messages on your behalf. That can save time and money both up-front and when it comes to maintaining the solution. However, that also means you’ll need to be happy with the functionality PubNub offers and continue to pay their fees for the life of your application. 

Because WebSocket is only a protocol, it requires that you build and tend to your own solution. That includes architecting, deploying, and maintaining the infrastructure necessary to keep that solution in production. That offers you flexibility on paper but, in practice, you’ll need a long-term plan and a budget for both headcount and infrastructure costs.

PubNub’s reliance on long polling puts it at a disadvantage compared to WebSocket. That’s mostly due to the inefficiencies that come about thanks to how long polling works. Rather than being a dedicated realtime protocol, long polling stretches HTTP beyond its original design. 

Usually, HTTP opens a connection, receives some data (such as HTML), and then closes the connection. Long polling opens a connection on the off-chance that there is some data ready for it to receive. It then waits until there is data or, otherwise, the connection times out. As a result of repeatedly opening new HTTP connections, long polling has greater overhead than WebSocket. The practical result is that PubNub suffers from higher latency than solutions built using WebSocket . 

Find out more about the differences between long polling and WebSocket here.  

WebSocket is a realtime communication protocol. That means that, beyond setting up and maintaining the connection, then delivering messages, WebSocket doesn’t do very much else. And that’s perfectly fine but it does mean that your engineering team will need to build other aspects of your solution. That could be at the lower level, such as the logic to reconnect after an interruption, or at the higher level such as typing indicators in a chat app.

Like other realtime PaaS providers, PubNub offers a more rounded solution. As well as delivering messages with relatively low latency, PubNub gives you related functionality. For example, serverless functions, mobile push notifications, message persistence, and user presence. To build similar functionality with WebSocket would require custom engineering work.

Choosing between PubNub and WebSocket can be a difficult decision. As we’ve seen, each solution operates at a different level. WebSocket is one tool that you’ll use alongside others, whereas PubNub aims to give you a more complete solution. 

To explore what this means in practice, let’s look at an example scenario. Let’s say you want to build chat functionality into an existing application. What are the practical implications of choosing either PubNub or WebSocket to do that?

How fast you can deliver functionality to end users impacts how quickly your business can see a return on its investment.

• WebSocket: Choosing WebSocket can mean choosing to build your own solution. That has a big effect on time to market because you’ll need to design, build, and test your custom solution, as well as ensuring you have access to the right cloud infrastructure. Alongside WebSocket, you’ll need to find other tooling to support message persistence, mobile push notifications, and similar functionality expected by chat users. All of that changes if you work with a realtime PaaS that supports WebSocket, such as Ably.

• PubNub: By providing you with the tooling and infrastructure for realtime messaging, PubNub can help you deploy a solution much faster than standalone WebSocket. And PubNub’s additional functionality, such as user presence tracking, saves you time you’d otherwise have to devote to creating that from scratch.

Software rarely stands still. Whether it’s responding to vulnerabilities or meeting new user demands, you’ll need to allocate engineering time and budget to keeping your chat functionality running. How does that differ between PubNub and WebSocket?

• WebSocket: Building your own realtime solution with WebSocket at its heart means that your engineering team will be responsible for all ongoing maintenance. And that’s not just a software engineering problem but also a DevOps issue to take care of the global infrastructure required to deliver low latency chat experiences.

• PubNub: As a PaaS, PubNub maintains both the software and the infrastructure side of the realtime solution. The benefit there is that you don’t need specialist realtime expertise on your engineering team.

For your chat service to feel responsive, you need to minimize latency within all parts of your system. Writing efficient code on your client-side will help but the greatest scope for variation is in the infrastructure delivering messages between your chat users and your application backend. While PubNub boasts a global network, which should reduce the time it takes for messages to travel between their network and your chat users, it’s hard to compare that with whatever you might build instead with WebSocket. So, let’s look at the protocols involved to make a fair comparison.

• WebSocket: As we saw earlier, WebSocket has been designed from the ground up to support realtime communication. That allows it to be much more efficient than older approaches, such as the HTTP long polling used by PubNub. While infrastructure might vary, the protocol overhead introduced by WebSocket is minimal and so your chat users will enjoy a more responsive experience.

• PubNub: Relying on HTTP long polling means that, no matter how extensive PubNub’s global network might be, there will always be an unnecessary overhead in setting up multiple HTTP connections in the hope that there might be a message waiting. This could result in a noticeably laggy experience for chat users.

Whatever other promises they make, one of the most important considerations when comparing the technologies you’ll use in a realtime system is how well you can rely on them. What happens when there’s a failure, for example? Can PubNub and WebSocket handle less than ideal network conditions?

• Recovery from failure: WebSocket doesn’t recover automatically when a connection fails. Instead, you need to create your own application logic to recover connections. PubNub, however, does recover dropped connections but can store only a limited number of messages during a failure. 

• Quality of service: Ensuring messages arrive in the right order and the right number of times is vital for your application. PubNub’s own marketing materials say that it is “not a guaranteed message delivery service”. WebSocket also doesn’t offer a message delivery guarantee but Ably, for example, does add message delivery guarantees on top of WebSocket.

• Geographic distribution: PubNub runs a global network, which means that theoretically a network issue in one location shouldn’t impact other parts of the network. For WebSocket, it all comes down to your implementation or that of the WebSocket-compatible realtime PaaS you use, such as our own here at Ably.

In each of these factors, both PubNub and WebSocket have their pros and cons. However, when evaluating your options for realtime infrastructure, it’s worth looking at more than just two solutions.

It’s likely that neither PubNub nor WebSocket by itself is entirely the best option for your realtime applications. So, what other options are available? 

WebSocket and PubNub fall into two broad categories. WebSocket asks you to build more of the solution in-house, whereas PubNub lets you buy-in a more rounded solution. So, let’s look at some of the alternatives through that lens.

• Socket.IO: An open source library that builds on WebSocket, Socket.IO improves on the protocol by supporting essential functionality such as automatic reconnections.

• Server-Sent Events (SSE): Like the HTTP long polling relied on by PubNub, Server-Sent Events uses HTTP connections. However, rather than opening requests opportunistically, SSE pushes data from the server to clients such as web browsers. Crucially, SSE sends data one way only.

• Firebase: As a backend as a service (BaaS), Firebase provides much of the infrastructure that developers need to create the backend of an application. While it does offer some realtime functionality, its scalability is limited.

• Ably: Ably builds on the best of WebSocket to give you a low latency, reliable, global, realtime PaaS. Let’s take a look in more detail at what Ably offers.

We’ve looked at how PubNub and WebSocket compare. On the one hand, WebSocket as a protocol offers low latency, full duplex, realtime communication but you need to build your own infrastructure to support it. PubNub, on the other hand, gives you the infrastructure to build realtime systems but at the expense of higher latency and lower reliability.

Ably gives you the best of both worlds and more. As a realtime PaaS that supports WebSocket, Ably gives developers the tools to create collaborative, realtime experiences without the setup and ongoing maintenance of scaling custom WebSocket infrastructure.

Here are some of the benefits of building with Ably:

• Global median round trip latencies of sub 65ms.

• Reliable message ordering and idempotency.

• More than 25 SDKs meaning it’s easy to integrate Ably with your existing tooling.

• Limitless scale with 99.999% SLAs.

As part of your evaluation of realtime options, explore our documentation to find out more and get started with a free developer Ably account.