The best pub/sub services: 5 pub/sub solutions compared

Choosing the right pub/sub platform is one of those decisions that will have a lasting impact on your application's future. As part of your critical infrastructure, it directly affects your application's performance, scalability, and reliability. And it can also influence how quickly you can get new functionality to market.

But it's not always obvious what sets one pub/sub service apart from another. That's why we're going to look at what you should expect from a pub/sub platform, some of the pitfalls to avoid, and core points of comparison, including:

• Reliability and resilience.
• Scalability.
• Developer experience and integration options.
• Overall and ongoing costs of building with and then operating your application with that platform.
• Any advanced functionality beyond pub/sub.

We'll also provide an overview of the market's most popular pub/sub offerings, to help you draw up a shortlist for your evaluation.

First, let's clarify what pub/sub actually is.

What is pub/sub?

Publish/subscribe (pub/sub) is an asynchronous messaging pattern that decouples message producers from message consumers. That flexibility makes it a great choice for creating event-driven application architectures, integrating with external services, and other scenarios where you need to manage potentially complex flows of data between independent services.

The core components of pub/sub are:

• Publishers: Services that emit messages with no need for any integration work directly with the services that will read those messages. For example, a financial data service pushing stock price updates to users of a trading app.
• Channels or topics: Similarly themed messages get grouped together in channels and each message is published to one or more of these channels. In our trading app example, each stock could have its own channel, allowing users to receive only the stock data they’re interested in. However, there might also be channels that send summaries for each stock exchange, such as the FTSE 100 or Dow Jones index.
• Subscribers: Services that subscribe to particular channels and ingest the messages on those channels, without having any direct contact with the services publishing those messages. In our financial data example, that could be mobile apps on end-user devices, automated trading systems, or a news aggregation platform.

This approach makes it easier to write code that publishes and consumes data across disparate systems because there's just one integration point: the pub/sub service. However, this also means putting a lot of faith in that one part of your infrastructure.

If the pub/sub service can't scale to handle the volume of data you're sending, or if it does a bad job of ensuring message delivery, it could degrade your end-user experience or even lead to downtime.

Take a look at our pub/sub guide to learn more about this architecture pattern.

Why use a managed pub/sub service?

If you choose the pub/sub route, it's essential that you can rely on the tooling you choose. For most teams, that means using a managed pub/sub platform rather than building a solution in-house.

In our own research, we've found that in-house realtime infrastructure projects have a strong tendency to run over budget and over time. And even after all that, they often cost more overall.

So, if you decide to use a managed pub/sub service, how do you choose the right one for your needs? As we noted in the introduction, at first glance it can be hard to differentiate between the different offerings available.

Let's expand on the criteria we'll use to compare some of the most popular options:

1. Scalability

The way platforms handle scalability affects both your costs and the user experience. Some platforms adjust automatically as demand changes, while others can't respond quickly enough or without manual intervention. If a platform can't scale automatically, you'll need to over-provision resources to prepare for peak times. This can result in idle resources during slower periods, leading to higher costs without any real benefit.

Here are some things to look out for when it comes to evaluating a pub/sub platform's scalability:

• Scale on demand: Can the platform handle spikes in demand?
• Automatic scaling: Do you need to plan for and manually enable scaling or does the platform respond automatically in a serverless manner?
• Scaling architecture: Does it scale out horizontally to multiple instances or scale up on a single instance?
• Multi-region scaling: Can the platform run across multiple cloud regions or datacenters?

2. Reliability

Reliability is the other side of the coin from scalability. That's because the architectural choices that help a platform scale also make it more resilient. This is especially true for scale out architectures, because their ability to operate across multiple instances, availability zones, or geographic regions also improves their ability to work around failure.

When comparing pub/sub services, you should look to see if they offer the following:

• Automatic failover: Can the platform maintain availability, even if one instance becomes unavailable?
• Message persistence: What happens if a subscriber temporarily disconnects? Can the platform hold onto the messages they miss, and replay them when they reconnect, or are they lost?
• Geographic redundancy: Can the platform boost fault tolerance by distributing load across multiple locations to work around broader cloud or internet issues?

3. Performance and low latency

Latency can mean the difference between delivering an end-user experience that keeps people productive and one that leaves them frustrated. As virtually all your application's data will pass through the managed pub/sub service you choose, it has a key role in whether you can provide a smooth, responsive service.

The architectural factors that determine whether your chosen pub/sub service can deliver low latency communication include:

• Datacenter locations: Does the provider have a presence near to your end users and the other parts of your application infrastructure? That could be in the form of core routing datacenters or edge points of presence that minimize the round-trip time from clients to the pub/sub platform.
• Protocol efficiency: The protocol the platform uses to connect publishers and subscribers can have a big impact both on the efficiency of handling messages and on the way you integrate the platform into your application. For example, Google Pub/Sub favors gRPC, which can be efficient but lacks support in browsers. PubNub relies on HTTP long polling, which is widely available but inefficient. Ably, on the other hand, offers WebSocket and several other protocols, to maximize the types of clients you can connect. Learn more about why we at Ably favor WebSocket, and alternative protocols for realtime experiences.
• Network robustness: How reliable is the underlying network infrastructure in handling high traffic volumes and ensuring consistent low latency performance?

4. Guarantees

If you can't trust that your messages will reliably reach their destination, you might question the value of using a pub/sub service at all. Surprisingly, many managed pub/sub platforms provide only basic guarantees, forcing you to add extra application logic to track and resend messages.

When comparing pub/sub services, guarantees typically fall into the following two categories:

Delivery guarantees: You'll encounter three main types: at most once, at least once, and exactly once.

• At most once means the platform only ensures that a message won’t be delivered multiple times. However, it could fail to deliver it altogether, and that would still satisfy this guarantee.
• At least once ensures the message will be delivered, but it might show up more than once, requiring you to handle deduplication on your end. Most platforms offer this type of delivery guarantee.
• Exactly once is the rarest and most difficult guarantee to achieve. It promises that each message will be delivered one time—no more, no less.

Ordering: Some platforms promise to deliver your messages in the order you send them, whereas others leave it to you to manage message sequencing on your own. This means that if order is critical for your application—such as in financial transactions or event-driven architectures—you'll need to implement additional logic to ensure that messages are processed in the correct sequence. Most platforms don't promise to deliver messages in the order you send them.

5. Development and operations

You should also consider how easy a pub/sub service is to work with. Is it easy to learn? How quickly can you use it to deliver new features? What demands will it put on your DevOps team?

So, alongside the platform's functionality, make sure to check out how well it does in the following areas:

• Developer experience: Are SDKs available for your preferred languages, frameworks, and platforms?
• Integrations: Does it integrate easily with other parts of your infrastructure?
• Monitoring: Can you observe the performance and status of your pub/sub platform?

6. Cost of ownership

As with many managed services, pricing tables don't always tell the full story when it comes to cost of ownership. There are three areas you should consider when thinking about which platform will give you the best return on your investment:

• Platform efficiency: Does the platform provide features to optimize message delivery? For instance, does it support batching messages to prevent traffic from growing exponentially as you add more clients? Or does it offer techniques like binary delta compression, which only sends the specific updates each client needs, reducing bandwidth usage and improving performance?
• Additional infrastructure costs: If the pub/sub platform doesn't offer some of the functionality that your application requires, such as exactly once delivery, you'll need to factor in the cost of running your own additional code to fill the gaps.
• Cost of development and operation: This includes the fees charged by the platform but also how much development effort it takes to integrate with the platform and the ongoing costs of keeping it running.

7. Functionality beyond pub/sub

As a messaging pattern pub/sub is only concerned with publishing messages to a topic or channel, and subscribers receiving messages from that topic. However most of the managed pub/sub services provide additional features that are easy to integrate and enable higher performing, feature rich applications to be created.

Some of the features that providers offer include:

• Push notifications direct to iOS and Android devices, as well as browsers.
• Message persistence, so clients can catch-up on following a disconnect.
• Message filtering, so that subscribers can choose which messages to receive from a particular channel.
• Presence enabling the automatic detection of a user’s connection status (offline/online).
• Connection state and recovery ensures you automatically re-establish failed connections and replay missed messages.
• Message batching enables the optimization of costs and enhances performance in large-scale, high-throughput applications.
• Subscription filters for selectively subscribing to messages on a channel using filter expressions.
• Dynamic channel groups enable automatic subscription to multiple active channels simultaneously that match your specified criteria.
• Create consumer groups that cooperate to consume data from certain channels.
• Significant bandwidth reduction when broadcasting changes using binary Delta compression.
• Support for multiple protocols, such as WebSocket, MQTT, and Server Sent Events, thereby expanding the number of clients that can connect to the pub/sub platform.
• In most pub/sub services, messages are consumed by application components. Where an end-user needs to receive a message, or a system cannot integrate directly with the pub/sub service, some platforms offer SMS and email delivery.
• SMS messaging as an alternative method of delivery messages to end-users. This is similar to how some platforms offer push notifications and email delivery.
• File sharing is a complementary aspect of many of the use cases enabled by pub/sub. For example, sending images in chat, sharing a spreadsheet with colleagues in a collaborative work environment, adding context to stock information with company press releases.
• Similarly, the ability to persist small amounts of data can make pub/sub platforms more robust and help enable other functionality, such as file sharing. That's why some pub/sub services offer lightweight storage.

Now that we have the criteria, let's use them to look at some of the more popular pub/sub platforms.

Comparing pub/sub services

Google Cloud Pub/Sub

Google Pub/Sub is a managed publish/subscribe messaging service that is deeply integrated with the Google Cloud ecosystem. However, it also offers server-side libraries for integration with your application code. Perhaps the biggest benefit of Google Pub/Sub is that it distributes your topics across the global Google Cloud network. Another thing to note is that it mostly uses the gRPC protocol, which could make it harder to integrate with browser-based applications.

Here’s how Google Cloud Pub/Sub performs on each of the key evaluation criteria:

Criteria	Performance
Scalability	Globally scalable across the Google Cloud network.
Reliability	Topics are distributed globally. Automatically redistributes load to work around failures.
Performance	Google Pub/Sub draws on the global Google Cloud network to offer high throughput, low latency message delivery. Its reliance on gRPC for communication is good for cloud native environments where gRPC is supported but the fallback to REST elsewhere could reduce performance.
Guarantees	Offers at-least once delivery by default. Can request exactly-once delivery within a single region when creating a subscription. Supports message ordering but doesn't guarantee it. 99.95% uptime guarantee and SLA.
Development & operation	SDKs limited to server-side integrations, rather than client-side. Integrates with Google's observability and monitoring tools.
Additional functionality	Message filtering based on customizable rules
Cost of ownership	Somewhat complex pricing that charges based on throughput, storage, data transfer, and other functionality.

PubNub

PubNub is a realtime messaging platform that uses the pub/sub pattern to deliver messages across its global network. It also offers functionality such as cloud functions, message persistence, and mobile push notifications. However, its reliance on HTTP long polling instead of more modern techniques can result in longer latencies than some alternatives. It also falls short when it comes to message delivery: rather than providing guaranteed message delivery, PubNub asks you to write your own functionality to take care of that.

Here’s how PubNub performs on each of the key evaluation criteria:

Criteria	Performance
Scalability	PubNub claims that it serves 800 million monthly active users and promises to support unlimited numbers of concurrent users and channels.
Reliability	PubNub only offers a 99.999% uptime SLA for pro customers. 15 locations worldwide. PubNub's message persistence can handle only 100 messages by default. If a client disconnects, it could lose messages unless you add your own message persistence and retrieval.
Performance	Promises less than 100ms latency for paid accounts. PubNub doesn’t use delta compression. That means it sends the entire payload in each transmission rather than the differences since the last time. This is less efficient and could lead to higher latencies, as well as higher costs.
Guarantees	PubNub makes no guarantees about message delivery or order. You'll need to write and manage your own application logic to take care of that.
Development & operation	Offers multiple SDKs, covering popular languages, frameworks, and platforms. Complies with standards such as SOC2, HIPAA, and ISO 27001.
Additional functionality	Presence Mobile notifications File sharing Lightweight storage Chat SDK that helps build chat-specific functionality like read receipts and mentions
Cost of ownership	Paid plans start at $98 per month, with usage on top. Support costs extra Need to consider the cost of running code to make-up for PubNub's lack of message guarantees

Pusher

Pusher is a lightweight pub/sub messaging platform that also lets you send native mobile notifications. What sets Pusher apart from other managed pub/sub services is that it offers a relatively basic solution. That means you'll need to write and maintain a lot more of your own code to make sure your messages reach their destinations. Things to look out for include operating in a single cloud region, making Pusher more fragile than alternatives, and no delivery guarantees.

Here’s how Pusher performs on each of the key evaluation criteria:

Criteria	Performance
Scalability	Pusher doesn't publish data about scalability. However, their most expensive self-service plan can handle 90 million messages per day and up to 30,000 concurrent connections.
Reliability	Uptime SLAs are available on enterprise plans only. Single location reduces reliability as you won't be able to work around cloud outages or broader internet issues. Pusher's lack of persistence means you'll need to integrate other storage tools in order to recover from client disconnections.
Performance	Pusher doesn't publish performance data. However, operating from a single cloud region means that end-users in other parts of the world will experience a degraded service.
Guarantees	Pusher makes no guarantees about message delivery or order. You'll need to write and manage your own application logic to take care of that.
Development & operation	Pusher offers official client and server-side libraries for typical technologies, such as iOS, React Native, .Net and Java. Where WebSocket is unavailable, Pusher falls back to HTTP long polling for greater flexibility.
Additional functionality	Mobile push notifications Presence indicators
Cost of ownership	Paid accounts start at $49 per month for 200k messages per day and up to 100 concurrent connections. Push notifications through the Beans product cost extra. Need to factor in the cost to run functionality to take care of message guarantees, persistence, etc.

Amazon SNS

Amazon's Simple Notification Service (SNS) is a managed pub/sub service that also offers SMS and mobile push notifications. As you might expect, it favors the Amazon ecosystem when it comes to integrations but it has a REST API and several SDKs. While it's designed for scale, individual topics exist only in a single region, which could limit scalability, resilience, and the ability to offer low latencies to end-users further from that cloud region.

Here’s how AWS SNS performs on each of the key evaluation criteria:

Criteria	Performance
Scalability	Amazon SNS automatically scales to handle millions of messages per second.
Reliability	SNS stores each message it receives across multiple availability zones. If one availability zone fails, the load is distributed across the remaining zones. Topics are confined to a single region, so to achieve lower global latencies and to improve resilience, you must replicate data across multiple topics in different regions.
Performance	Amazon SNS claims nearly unlimited throughput for topics where message order is not guaranteed. FIFO topics, where ordering is guaranteed, support up to 300 messages per second.
Guarantees	SNS guarantees delivery, so long as the endpoint is available. In standard topics, messages might arrive out of order FIFO have limited throughput but guarantee order. Messages could arrive more than once in standard topics but are deduplicated in FIFO topics.
Development & operation	Extensive documentation and integrations but notoriously complex auth system Integrates with Amazon's observability and monitoring tools.
Additional functionality	SMS Mobile push notifications
Cost of ownership	Pay as you go model starts at $0.60 per million notifications (US East region).

Ably

Ably is a realtime experience platform, serving more WebSocket connections than any other pub/sub platform. Originally just a pub/sub service, they now offer a suite of products to accommodate different developer needs and use cases, including: Ably Pub/Sub, Ably Chat, Ably LiveSync and Ably Spaces. Accessed via simple APIs, use case specific SDKs and pre-built integrations, this product set enables the creation of a host of live experiences - including data broadcasts, live updates, chat, collaboration, notifications, and fan engagement.

Underpinned by a globally-distributed network of datacenters and edge acceleration points of presence, all products benefit from <50ms global median latency, with guaranteed message ordering and exactly once delivery. Capable of scaling to handle millions of concurrent clients, with redundancy built in at a regional and global level.

Here’s how Ably performs on each of the key evaluation criteria:

Criteria	Performance
Scalability	Global datacenters with an additional edge network, plus 50% headroom capacity to enable instant scaling across the world. Uses horizontal scaling to support unlimited channels, concurrent connections, and message throughput on aggregate.
Reliability	Replicates messages across availability zones to mitigate against failure. Automatic failover to geographically separate datacenters should a location suffer an outage. Global fault tolerance with 10x9s survivability. Persist messages to enable playback when devices reconnect.
Performance	Less than 50ms roundtrip latency for the 99th percentile, within the edge network.
Guarantees	Guarantees message delivery. Guarantees message order. Will deliver each message exactly-once. 99.999% uptime SLA.
Development & operation	Broad range of SDKs covering popular frontend, backend and mobile languages and frameworks. Supports multiple protocols, including WEbSocket, MQTT, SSE, and more. Excellent documentation. Integrations with popular tooling such as Apache Kafka and Apache Spark. Use case specific SDKs for chat and collaboration.
Additional functionality	Presence Web & moile push notifications Message persistence Connection state recovery Message batching Subscription filters Dynamic channel groups Consumer groups Bandwidth efficient deltas
Cost of ownership	Pay as you go pricing starts at $2.50 per million messages, $15 per thousand concurrent channels, and $15 per thousand concurrent connections.

Get started with Ably today

Out of all the options available for adding pub/sub functionality to your application, for most teams a managed pub/sub service offers the best trade-offs when it comes to cost, development effort, maintenance, reliability, and functionality.

But not all managed pub/sub platforms are alike. As we've seen in our comparison, most pub/sub platforms ask you to compromise on at least one important factor. That could be delivery guarantees, latency, scalability, or developer experience.

Ably is different. Our managed WebSocket infrastructure is built to serve the world’s most demanding realtime workloads, and is trusted by leading brands to power their critical applications. Coupled with the rich feature set offered through our Ably Pub/Sub product, we enable developers to rapidly develop any live and interactive experience with confidence. Sign up for a free account to start experimenting and building with Ably's managed pub/sub service.