Pusher vs Stream (GetStream)

The details differ quite considerably between Pusher and Stream and that stems from one core reason. Both Pusher and Stream set out to solve different problems:

• Pusher is a general purpose messaging platform that helps you distribute messages using WebSocket.

• Stream is an API and platform that specializes in higher level functionality including chat, video and audio, and activity feeds.

The impact is that Stream can help you solve a limited range of problems but with less custom development on your part, whereas Pusher is open ended but requires more effort. 

So, which should you choose? First, we need to look in more detail at what both products offer.

Pusher, which is part of the MessageBird suite of tools, is a general purpose messaging PaaS and offers two distinct products:

• Pusher Beams: Web and mobile push notifications.

• Pusher Channels: Low latency message delivery using publish-subscribe.

Pusher Beams is pretty straightforward. It gives you a single API to deliver push notifications to iOS, Android, and web users. Pusher Channels is a little more involved, offering a platform for two-way messaging between clients and a central Pusher backend.

There's some room for confusion here because "message" has a different meaning in the context of chat versus realtime systems, so let's clear that up before we move on. For Pusher, messages are self-contained packets of data that publishers, such as one of your backend services or the client on an end-user's mobile device, emits to a topic, which is then consumed by subscribers in the form of other end-users and services. 

Pusher's job is to take care of consuming and delivering messages to the right place. But does it do a good job? We can get a quick overview by reviewing Pusher's pros and cons.

• Use case flexibility: Pusher is a general purpose pub/sub messaging platform. That means you can use it to create a wide range of event-driven applications.

• Available in many languages: Pusher provides SDKs for frontend clients, including web and mobile platforms, as well as several backend frameworks, including Rails, Node.js, and .NET.

• Protocol fallback: Pusher's protocol uses WebSocket, meaning it's available just about everywhere. However, if there's a problem with WebSocket, Pusher can also switch to HTTP streaming and HTTP polling.

• Compliance and security: Pusher can encrypt private channels and it complies with GDPR and ISO27001. While Pusher doesn't comply with HIPAA by default, the company does offer guidance on how to achieve HIPAA compliance using their platform.

• Pusher provides low-level tooling: Building a chat solution on top of Pusher will take more work than using a dedicated chat platform as a service (PaaS) tool like Stream. That means more code to write and maintain.

• Weak guarantees: A PaaS like Pusher has one job: to get your messages to their destination. Unfortunately, Pusher doesn't guarantee that your messages will reach their destination. Instead, it says that they will be delivered "under normal system operation". That means you need to build your own message tracking functionality. There's also no guarantee over message ordering, which could lead to messages arriving in the wrong order.

• No message history: There are times when clients disconnect or otherwise can't receive their intended messages. In those cases, you'll need some other mechanism to store message history because Pusher doesn't store messages.

• Limited to one region: Pusher routes all of your data through a single location, meaning that it is vulnerable to outages and other degradations in service. That also impacts user experience because end-users further away from the cloud region will necessarily experience higher latencies.

Stream takes a different approach to Pusher. Rather than giving you the building blocks to create your own solutions, Stream offers use-case specific APIs and infrastructure for:

• Chat

• Audio and video calling

• Activity feeds

• Automatic moderation

• AI chat bot integration

Rather than providing lower-level realtime infrastructure, Stream aims to give you an out-of-the-box tool to solve specific problems. That distinguishes it from Pusher in two key ways: it does much more for you but offers less flexibility.

We should get a better understanding of what makes Stream a good option and where it has weaknesses.

• Time to market: Stream's website promises to help you build a chat app in days. If Stream's solutions meet your needs, it's likely that you can get your chat functionality to market far quicker than with a generalized tool like Pusher.

• Little ongoing maintenance: Because Stream provides chat functionality out of the box, it means there's less original code and infrastructure for you to maintain than when using Pusher. 

• Edge network: By running a global network of servers, your end-users could experience lower latencies with Stream when compared to the single cloud location offered by Pusher. But that's dependent on the geographic location of your users and other factors, such as the efficiency of the code running within Stream's network.

• High capacity: Stream claims to support up to 5 million concurrent connections in a single channel.

• Strong uptime if you pay for it: With a promise of 99.999% uptime for enterprise customers, Stream promises a reliable solution if you are willing to pay higher prices. Stream offers a relatively unambitious 99.95% uptime for lower-priced packages, which is equivalent to more than four hours of downtime each year.

• Complies with standards: Stream Chat and Feeds comply with SOC 2 and HIPAA. 

• Ready-made chat UI kits and other integrations: Stream gives you a headstart with chat UI components and backend SDKs for various frameworks and languages.

• Limited to specific use cases: Stream isn't a general purpose realtime platform. That might make it easier to get set up initially if you need chat or activity feeds - but as soon as your needs no longer align with what Stream has to offer then you'll either have to migrate to a more flexible platform or change your product plans.

• Can be expensive: The convenience of Stream's ready made solutions comes at a price. The cheapest paid-for plan is $499 per month (or $399 per month if paid annually), supporting 10,000 monthly active users (MAU). However, things get really expensive once you exceed that user limit with a charge of 9 cents per month for each additional MAU and 99 cents for each additional concurrently connected user. If you were to meet Stream's claimed 5 million concurrent user capacity then you would pay an overage fee of $5,398,605 per month, based on list prices.

• Lack of data ownership: When working with Stream, your chat data must reside in their database. That could cause issues depending on how sensitive the data is and whether it is covered by regulations that Stream does not meet. It could also be harder to integrate with third-party systems, such as observability platforms or data stores, as you have less access to the data underlying Stream's services.

As we've seen, Pusher and Stream can both help you to build chat functionality into your application. However, the approach they each take differs greatly. Of course, the most obvious difference is that Stream provides you with a tailored chat solution, while Pusher gives you greater flexibility to build any kind of messaging based functionality. But there are other differences, too, in terms of how they perform and the developer experience they offer.

Let's look at them both, side-by-side.

Both platforms are only useful if they perform when you need them. So, can you rely on Pusher and Stream?

Chat users expect rich features, such as typing indicators, reactions, emojis, and user presences. How do Pusher and Stream compare?

Can you use Pusher and Stream with the languages and frameworks that you need?

Before you can trust your data, and your users' data, to a third-party platform you need to be sure that it meets the right security requirements.

Pusher and Stream both offer products that enable you to create chat experiences, but Stream gives you a lot more functionality out of the box. That's reflected in the pricing, with Stream's packages reflecting the fact that they offer richer functionality.

Choosing between Pusher and Stream is a little tricky because the problems they solve exist at different layers of abstraction. Stream gives you a ready-made chat solution, whereas Pusher offers the infrastructure with which you could build your own custom chat.

So the first question is: does your problem fit Stream Chat's offering or do you need the flexibility to build something different? If you need the flexibility that Pusher offers, then Stream isn't going to be the right choice. But if you're still not sure which one offers the right solution, let's look how they compare.

• What you can build: With Pusher you can build anything that requires low latency messaging. Stream offers solutions to specific problems, such as Chat and Activity Feeds.

• How much work you'll need to do: Stream gets you from idea to finished functionality faster than Pusher. It also reduces the amount of maintenance you'll need to do, so long as Stream fits your needs. With Pusher, you get the functionality but you have to maintain the custom solution you build on top of it.

• Tooling and integrations: Pusher isn't a standalone solution. You'll need to integrate with a database and object storage, at the very least, to handle message history and file storage.

• Pricing: Pusher will charge you less than Stream but you'll need to do more of your own engineering and infrastructure work if you choose Pusher.

• Single point of failure: Pusher and Stream run your functionality in a single location. Stream's Edge network has the potential to improve latency over Pusher but neither Pusher nor Stream offers a multi-region option, making your chat application vulnerable to outages.

For a pure chat project, where you are happy with Stream's design choices and functionality, Stream probably offers the better option. That's because Pusher will ask you to do a lot more work but without giving you much additional functionality in return. For example, Pusher can't give you guarantees over message delivery or multi-region support, meaning that you could end with a greater maintenance burden but without any noticeable improvements in user experience.

However, if you need to build a variety of low latency applications then Stream won't be able to help. However, that doesn't necessarily mean you should choose Pusher. In fact, there are several realtime platforms to choose from. In particular, Ably  gives you much greater flexibility than Stream while offering a more robust service than Pusher.

Ably is a realtime experience platform used by HubSpot, I7Live, SportsBet, InvitePeople and more to power their fully-featured and reliable chat.

Our new product, Ably Chat, is designed to deliver a great chat experience for use cases from livestreams and in-game communication to customer support and social interactions in SaaS products.

It comes with purpose-built APIs for quickly building out chat features, including realtime messaging, online status and presence tracking, typing indicators, and room-level reactions. Built on Ably's core platform, Ably Chat streamlines the complexities of realtime chat architecture, providing a powerful and flexible solution for a wide range of use cases.

Even outside of chat, one of the great advantages of Ably is that it gives you the platform to build and operate any realtime functionality. That includes multiplayer collaboration, data broadcast, and IoT device communication. And Ably does that with stronger reliability and lower latency than either Pusher or Sendbird, thanks to:

• Global network reach: You don't need to choose just one location. Instead, Ably distributes your workloads across a global network of edge locations.

• <50 ms latency: Ably operates in realtime, no matter where your end users are located, thanks to ultra low latencies.

• Strong guarantees: Ably guarantees that messages arrive in order and on time, saving you from having to build additional code to track and resend messages.

• 99.999% uptime: Ably’s dedicated team works 24/7, so you can have peace of mind even during high-demand periods.

• Elastic scaling: From thousands to billions of messages, Ably meets your application’s demands seamlessly.

• A great developer experience: with SDKs targeting more than 25 languages and frameworks, integrations with common tooling, and industry leading documentation, Ably’s developer experience gives you the tools to become productive quickly.

Discover how Ably empowers you to integrate global, scalable, and efficient realtime experiences of all kinds.