Ably vs PubNub
Find out why Ably provides more serious and dependable realtime APIs than PubNub.
Easily build complete, trusted realtime functionality.
Take our APIs for a spinInformation provided is from publicly available sources and is intended as a starting point for further investigation. See full disclaimer.
Performance and availability | Ably | PubNub | Why does it matter? |
---|---|---|---|
Global datacenters | 15 Ably has 15 datacenters spread across four continents so your users are never far from the Ably network. We ensure complete availability by routing to the next-closest alternative datacenter when necessary. |
15 (source PA1) |
A global physical data center presence means you can bring your users closer to your data. This reduces latency while ensuring high availability. Find out more about Ably’s network |
Edge acceleration Points of Presence (PoPs) | 205 Ably’s edge acceleration PoPs extend our network coverage to clients connecting from locations further afield from core routing data centers, reducing volatility and latency when connecting into the Ably network. |
Unknown. | Acceleration Points of Presence (PoPs) ensure more stable connections and low latency for clients connecting into a network, improving their experience. Find out more about Ably’s PoPs and their 205+ locations |
Latency based routing | Yes. Ably offers latency based routing that ensures users anywhere in the world connect to the closest datacenter or edge acceleration PoP available to them – ‘closest’ meaning the datacenter with the lowest latency. |
Yes. (source PA2) |
Physical proximity doesn’t always equal lowest latency. With latency based DNS routing clients are connected based on latency, not location. Learn more about Ably’s latency based DNS routing |
Binary encoded messages | Yes. | No. (source PA3) |
Encoding messages in binary format is faster as it reduces bandwidth for sending and receiving messages, and streamlines the processing time for clients and servers when encoding and decoding messages. Learn about our binary protocol |
Global median round trip latencies of sub 65ms | Yes. Ably’s round trip latencies, measured as the time taken to publish a message on one connection and receive a message on another connection, dependably range from 5ms to 200ms, with a median global latency of 91ms. |
Unknown. PubNub advertises sub-250ms worldwide latencies. (source PA4) |
Predictably low latency means you can build knowing concrete parameters of performance, designing a better system and end-user experience around that. View third-party benchmarking stats |
Redundancy, reliability, integrity of data | |||
Realtime service mesh architecture with no single point of congestion | Yes. Ably’s realtime service mesh ensures no single point of congestion or failure, designed to always route messages with the least number of network hops. |
Yes. PubNub is also a distributed platform. |
Having no single point of congestion enables the lowest latency and highest availability. Learn about Ably’s mesh architecture |
No central point of failure | Yes. The Ably global platform is a distributed system designed with no single point of failure. All customers benefit from running their apps in all of our datacenters providing resilience, reliability, and global low latencies. |
Yes. PubNub is also a distributed platform. |
Data replication in multiple regions protects against single points of failure and ensures resilience and reliability of service. Learn about how we mitigate against a single point of failure |
Self-healing clusters | Yes. The Ably service uses a consensus algorithm to communicate between servers, meaning any issues are isolated, intelligently fixed and replaced, and traffic routed to healthy servers. |
Yes. PubNub is also a distributed platform. |
Automatic traffic rerouting, server isolation, and repair limit the risk of network problems, ensuring a better quality of service for you and your end-users. Learn more about our self-healing clusters |
Autonomous datacenters | Yes. Ably’s datacenters are designed to operate as part of our global cluster when available, but operate autonomously when necessary. |
Yes. PubNub is also a distributed platform. |
Datacenters that operate as part of a global cluster, but also autonomously when needed, provide high availability of service. Find out where Ably’s servers are located |
Data replicated in multiple regions | Yes. | Yes. (source PA5) |
This ensures that an outage in any datacenter or region cannot result in data loss. Find out about Ably’s message delivery guarantee |
QoS & message delivery guarantee (Unique to Ably) |
Yes. Ably provides guaranteed message delivery and continuity across disconnections. Publishers only receive an ACK when data is persisted in two locations, and subscribers never lose data during brief disconnections as we maintain connection state for each client on our servers. |
Unknown. | Upon a disconnection, retaining all messages on channels a client was subscribed to, and sending when the client reconnects and resumes its state, ensures messages are never lost and your end-users always receive messages. Find out about Ably’s QoS and message delivery guarantee |
Continuity and connection state recovery (Unique to Ably) |
Yes. Ably provides continuity for clients that become disconnected for reasons such as going through a tunnel or changing networks. We store the connection state for each client on our servers so that clients that reconnect within two minutes can resume their connection and receive all messages published whilst they were disconnected. |
Partial From PubNub: “The default message queue size is 100 messages. Consequently, publishing past 100 messages inevitably results in older messages overflowing the queue and getting discarded.” (source PA6) |
Storing connection state means clients can resume from where they left off, providing a better quality of service as nothing is ever lost. Find out more about connection state recovery |
Uptime guarantee |
Yes. Ably offers varying levels of uptime guarantees depending on your needs. For all of our enterprise customers we provide a 99.999% uptime SLA. If we are unable to meet your SLA goal, we offer refunds. |
Yes. | Confidence in a service to offer refunds on any downtime. That is what an uptime guarantee means, and it shows a provider values you and your end-users’ experience. Learn what we mean with our uptime guarantee |
Core features | |||
Channel presence | Yes. Ably supports a configurable number of presence members and supports 200 members by default, with many more upon request. We also support member state updates such as GPS device location. |
Yes. PubNub supports presence with a default max limit of 100 announce members per channel. (source PA7) |
Presence allows you to subscribe to events when users or devices enter or leave channels. This is a useful feature for collaborative apps, games and chat rooms. Find out more about Presence |
Message history (persisted data) | Yes. Ably’s message history feature provides a means for clients or servers to retrieve messages that were previously published on a channel. |
Yes. | Clients connecting to a channel can view messages previously published on that channel. This includes instant message rewind upon connection. Find out more about our History API |
Reliable message ordering (Unique to Ably) |
Yes. Ably ensures that messages are delivered to persistently connected subscribers in the order they were published on each channel using the First-in-First-Out (FIFO) pattern. |
No. (source PA8) |
For many realtime features, like chat or live collaboration, the ordering of messages is paramount to the end-user experience. Find out more about reliable ordering |
Idempotent message publishing | Yes. Ably supports idempotent publishing across all our native client library SDKs. |
Unlikely. PubNub’s recommended design pattern- for publish timeouts is to try the publish again which can result in duplicate publishes. For this reason, and the lack of any documentation that exists, we believe it’s unlikely idempotency is supported. (source PA9) |
Idempotent REST publishing assures published messages are only processed once, even if client or connectivity failures cause a publish to be reattempted. Learn more about idempotent publishing with Ably |
Delta Message Compression | Yes. Ably supports message delta compression on a per channel basis. |
No. PubNub does not support message delta compression according to their documentation and SDKs. |
Delta compression reduces the bandwidth costs required to transmit realtime messages by sending only changes to a stream instead of the entire payload each time. Learn more about Delta Message Compression |
Push notifications | Yes. Ably provides a unified API to deliver push notifications, including native iOS and Android push notifications. |
Yes. | Send native push notifications to all your end-users. Find out more about Push Notifications |
Message and worker queues (Unique to Ably) |
Yes. Data published into Ably’s realtime system can be moved into traditional message queues for realtime or batch processing. We also support AWS SQS, RabbitMQ, and AMQP. Ably handles all the complexity of doing so. |
Partial. PubNub does not offer any native message queue service or mechanism to distribute data using once-only pattern to your server workers. However, it does integrate with services such as Amazon SQS which do provide this. (source PA10) |
Queuing helps scale the consumption of realtime messages. Find out more about our Queues |
Webhooks | Yes. Ably’s Webhooks provide a means to get messages, channel lifecycle and presence events pushed to your servers over HTTP. |
Partial. PubNub supports Webhooks for presence natively, and recommends the use of Blocks for triggering Webhooks for message events. (source PA11) |
Publish messages and channel lifecycle and presence events to your own servers over HTTP so you can trigger events in your existing systems and execute on business logic. Find out more about Webhooks |
Serverless cloud function invocation (Unique to Ably) |
Yes. Ably can trigger serverless functions on any third party cloud providers such as Amazon Lambda, Microsoft Azure or Google Function. |
Partial. PubNub allows you to run code on its own platform using proprietary PubNub Functions in the form of “Blocks”. The code you can run in Blocks is limited to the Javascript API available in PubNub’s system. (source PA13) |
Trigger events in other cloud systems in response to realtime messages so you can execute on business logic. For example, on-the-fly translation. Find out more about Reactor Events |
Third-party services integration | Yes. Ably can link to third-party services such as Cloudflare Functions, Zapier, IFTTT, and Tray.io. |
Yes. PubNub’s Functions offers some pre-built Blocks from third-party services. |
Similar to Ably, third-party platforms such as Cloudflare and Zapier do a lot of the background heavy lifting to provide increased automation and functionality while reducing operational overhead. Being able to easily link your realtime operations to these existing services means creating even richer, more powerful realtime experiences. Learn more about third-party integrations |
Realtime data firehose (Unique to Ably) |
Yes. Stream your realtime data published within the Ably platform directly to another streaming or queueing service such as Amazon Kinesis, Apache Storm or Kafka, AWS SQS, and RabbitMQ. |
Partial. PubNub provides bridges for Kafka and NATS; however, the bridge is designed to stream data out of Kafka or NATs to PubNub. The Ably Firehose is designed to solve a different problem, streaming data from your clients connected to Ably into your streaming or queueing services. (source PA14) |
Linking systems together is a common requirement as services are responsible for different things. Easily being able to do takes unnecessary engineering strain off you. Find out more about our Reactor Firehose |
Custom domain endpoint (CNAME) | Yes. Ably supports custom domains for our Enterprise customers allowing them to connect to Ably using a CNAME such as “realtime.your-company.com”. |
No. PubNub only provides support for custom CNAME for non-TLS connections as it does not serve up custom certificates for customers. |
Comply with security policies and firewall restrictions with custom CNAMEs. Find out more about our custom domains |
Distribute data streams to third party developers (Unique to Ably) | |||
Optionally deploy, manage, and distribute data streams to third party developers | Yes. Deploy data streams to Ably’s managed infrastructure, manage and control who can access those data streams, and distribute them to third party developers as realtime APIs – so they can consume and integrate them into their own apps. |
Unknown. We have not identified any documentation that indicates PubNub provides functionality comparable to API Streamer. |
As realtime API adoption increases so does complexity, cost, and friction of integration for developers wanting to consume realtime data. Being able to easily distribute data streams future-proofs product development requirements and eases API programme creation. Learn more about API Streamer |
Complete management layer | Yes. | Unknown. We have not identified any documentation that indicates PubNub provides functionality comparable to API Streamer. |
This management layer drastically reduces the complexity, cost, and friction of creating self-service realtime API programs that are easy for developers to integrate with. Ably is first to offer this to market. Learn more about creating realtime API programs built on Ably’s network |
Client libraries and protocol support | |||
Native client libraries for every popular platform | Yes. Ably provides 40+ client library SDKs for a considerable range of popular platforms. |
Yes. PubNub offers a range of client libraries |
You should be able to integrate with the technologies and platforms you’re already building with. View our client library SDKs |
1st class WebSocket support | Yes. The Ably protocol is WebSocket-based with first-class WebSocket support. |
No. PubNub uses HTTP as the transport for their client libraries. A WebSocket compliant interface is provided in some libraries, however this is just a wrapper around an underlying HTTP transport. (source CL1) |
WebSocket is a widely-supported, bi-directional, feature-rich transport suitable for a range of realtime uses. View our supported transports |
Fallback to Comet (XHR) and Long Polling for older browsers | Yes. | Yes. | Whilst most modern devices support WebSockets, there are situations where the device or the network environment requires use of HTTP transports. View our supported transports |
Support for proprietary protocols of other realtime platforms (Unique to Ably) |
Yes. The Ably platform is designed to be protocol-agnostic and ensure protocol interoperability. We support other proprietary realtime protocols and ensure interoperability with Ably’s protocol and the other protocols we offer. |
No. | It should be easy to migrate from, or to, one realtime provider to another. Learn more about our Protocol Adapters |
MQTT support | Yes. The Ably platform is designed to be protocol-agnostic and ensure protocol interoperability. Ably supports MQTT |
Yes. | MQTT provides a lightweight messaging protocol for small sensors and mobile devices, optimized for low-bandwidth or unreliable networks. MQTT libraries already exist for almost every IoT device around. Find out which protocols we support |
Server-Sent Events (HTTP Streaming) protocol support | Yes. | No. | Server-Sent Events is a lightweight, subscribe-only protocol for when your end-users need only to receive new event data. Find out which protocols we support |
AMQP and STOMP | Yes. | No. | AMQP and STOMP protocols are for provisioning queues and configuring routing, among other things. Learn more about AMQP and STOMP at Ably |
Security | |||
TLS connection | Yes. | Yes. | TLS connections ensure all data in transit is encrypted. Find out more about SSL/TLS |
Token based authentication | Yes. Ably allows configurable policies and an identity to be embedded in a token ensuring you have complete control over what actions your users can perform such as limiting which channels they can subscribe or publish to. |
Yes. | Token based authentication ensures your private key is never shared and instead a short-lived token is used to authenticate. Find out more about Ably’s authentication |
JSON Web Token support | Yes. Ably allows for not only Ably Tokens to be embedded within JWTs, but also for JWTs to be signed by Ably API keys and used themselves for authentication. |
No. (source CL2) |
Using JWT allows for easy integration with your existing authentication systems, along with ensuring your private key is never shared. Find out more about using JWT with Ably |
Configurable private key permissions | Yes. Ably provides support for private API keys with configurable permissions including restrictions on channels or operations. |
No. PubNub does not provide configurable private key permissions. It uses a different model where each client’s access is configured with the PubNub Access Manager (PAM). |
API keys are a standard method for securing access to an application. Find out more about API keys |
Configurable channel permissions | Yes. Ably’s channel rules provide you with the flexibility you need to build rich and secure realtime apps. |
Yes. | Maintain control of your channels, such as requiring SSL/TLS or only identified authenticated clients on a channel. Find out more about channel rules |
Encryption for message payloads | Yes. Ably supports AES encryption. |
Yes. PubNub provides AES encryption. |
Encryption allows messages to be encrypted using the provided private key before they are published. As a result, messages are practically impossible to intercept and view for anyone. For very sensitive data, this ensures you can safely use us knowing your payloads are always secure and opaque. Find out more about Ably’s encryption |
Compliance | |||
EU GDPR compliant | Yes. Procedures and processes in place for EU GDPR regulation. |
Yes. | EU GDPR is regulation introduced to protect consumers and their data. Learn more about GDPR |
SOC 2 Type 2 compliant | Yes. | Yes. | SOC 2 Type 2 is a standard designed to help measure how well service organizations conduct and regulate information. The purpose of SOC standards is to provide confidence and peace of mind for organizations when they engage third-party cloud vendors. Learn more about SOC 2 Type 2 |
HIPAA compliant | Yes. Ably has many customers in the healthcare industry that we provide Business Associate Agreements to. |
Yes. | HIPAA stipulates how Personally Identifiable Information in healthcare in the USA should be protected. Learn more about HIPAA |
Value | |||
Transparent usage based pricing | Yes. Ably’s pricing is simple and transparent. You pay for the messages, peak active channels and peak connections you use for the month. You can either pay for what you’ve used at the end of the month, or reserve capacity in advance each month and benefit from a discount. |
It’s complex. PubNub follows a usage-based pricing model. However, pricing is based on over 60 different transaction types, making it difficult to predict ongoing costs. (source CL3) |
Pricing should be clear, flexible, and scalable when it comes to realtime messaging. Calculate your usage with Ably’s pricing calculator |
Other important stuff | |||
Theme tune | No. |
Yes |
Unfortunately at Ably we’ve been laser focussed on building the most robust and scalable realtime platform on the planet. As such, we haven’t yet had time to schedule the creation of a theme tune into an engineering sprint. PubNub clearly wins on this front! See and hear PubNub’s theme tune |
The comparisons presented here are: (i) derived from public information and open sources available as of September 2021, and thus may be outdated; (ii) intended as a starting point for further investigation; and (iii) not guaranteed to be 100% accurate or complete. The reader is encouraged to conduct an independent evaluation and to not rely solely on the information presented here. Please contact us if you believe the information here is inaccurate or incomplete.
PubNub references:
PA1, PA2, PA3, PA4, PA5, PA6, PA7, PA8, PA9, PA10, PA11, PA13, PA14, PA15, CL1, CL2, CL3
What our customers are saying about Ably
Migrating to Ably
Join the others and upgrade your realtime platform.
TECHNICAL DEEP DIVES
The engineering behind Ably's realtime APIs
-
datasheet
Pub/Sub ChannelsClass-leading realtime APIs to stream data from any device, to any platform, and any number of subscribers.
-
datasheet
Protocol AdaptersEliminate lock-in and simplify engineering architecture with universal protocol interoperability.
-
datasheet
IntegrationsThe flexibility to bring your compute and business logic closer to the Ably network so you can process and transform data in motion.
-
datasheet
Using the Ably platform at scaleAbly is designed to scale horizontally. In principle any arbitrary load can be handled. But there are always practical limits.