PubNub Pricing and the Move Away from Device Counting

For years, PubNub’s pricing model has been based on two major components:  the number of connected devices, and the number of messages sent/received through our network.  Originally, this model seemed like a good idea because it fit with the way customers were using PubNub. Our philosophy has always been to have a frictionless, “cost-plus” based pricing model that scales along with our customers’ growth and this pricing aligned with that approach at the time.

The Move from Device-Based Pricing

Along the way, as we’ve added over hundreds of thousands of developers and thousands of paying customers to the platform, we learned that device-based pricing doesn’t always align with our customers’ needs.  Customers found that if they wanted to do something like putting PubNub on their homepage, it would be cost-prohibitive because the number of devices could unpredictably spike, along with their costs.  We saw several customers spending time optimizing their code to reduce PubNub connections, thus reducing device counts, but, in the process, they would often create a sub-optimal user experience. To address this issue we ran a deep analysis of our monthly petabyte-sized transaction volumes to better understand what model would most efficiently align our costs with how customers are using the platform.  This analysis has helped us create a pricing model that gives customers the ability to get charged for exactly the APIs they use, and nothing more, ensuring that more use cases can be done cost-effectively on the PubNub platform.

Transaction-Based Pricing

So, based on the analysis we did as well as from feedback we’ve collected from customers already on this new pricing model, PubNub will be moving to a Transaction-Based Pricing model and rolling it out to all of our customers over the upcoming months. Here’s how the pricing works. PubNub has a little over 50 different API calls accessible on the platform, including Publish, Subscribe, History, Presence APIs, Access Manager APIs and Stream Controller APIs.   After some deep analysis of how customers are using the platform, these APIs were split into three categories:

• Replicated Transactions – These are API calls that replicate data around all our global Points of Presence (PoP).  Examples include Publish() and Grant() API calls.
• Edge Transactions – These API calls affect only a single PoP, such as Subscribe(), History(), and hereNow().  Most PubNub API calls fall into this Edge category.
• Free Transactions – These are APIs that we don’t charge for, the Time() and Fire() APIs.

All replicated transactions have one price, and all edge transactions have another.  To learn more about the different types of Replicated, Edge, and Free Transaction types, see this list. There are two other components to pricing.  Function Executions and Data Persistence (which is used by Storage & Playback, Channel Groups, and other storage based services).  These components to our pricing model don’t change.  However, note that the free usage period for Storage and Playback service will be ending May 1. There are many benefits to this new model.  You pay exactly for the transactions you use, nothing more.  There’s no penalty for lots of connected devices, and your costs will scale as users engage with your PubNub-powered product.  We also have discounts available for transactions pre-pays on the Pro plan, and offer lots of architectural help to make sure you’re using PubNub in the most efficient ways.

Timing of Transition

Over the next few months our customers will receive an email from PubNub explaining the new pricing model, and the timing for the change.  In some cases, your costs may decrease in the new model, in other cases, your costs may increase.  We realize that pricing model changes can always be disruptive, so we’ve ensured that we have people here at PubNub to help explain the new model, structure a smooth transition plan for your company, and help explain the best ways to leverage PubNub to optimize features and cost.