Transparent pricing that rewards success, not penalizes it"

Why realtime platforms need pricing models that align with customer value, and how competitors optimize for “simple” inefficient models

Nov 05, 2025

In the last week I’ve shared how Ably’s architecture enables things competitors thought were impossible: zero impact during a major AWS outage, scaling WebSockets to billions of connections globally, stream integrity guarantees at global internet scale.

Today: Pricing models that reward customer success instead of penalizing it.

Why pricing models matter

When we started Ably, we had a clear motive: deliver the best value, fairest pricing, and maximum transparency so businesses could succeed with our platform. That’s why we started the business in the first place.

Your pricing model either aligns with customer success or creates friction. It either rewards growth or penalizes it. And in realtime infrastructure, where usage patterns can vary dramatically, this matters more than almost any other SaaS category.

Three approaches to pricing

The industry has evolved three primary pricing models for realtime platforms. Let’s compare them directly.

Package-based Pricing (used by Pusher)

How it works: Fixed tiers that bundle multiple dimensions together (connections + messages + channels).

Example: Startup plan ($49/month) = 1M messages/day + 500 concurrent connections [1]

What happens when limits are exceeded: According to Pusher’s own documentation, when you hit message limits, you cannot publish any more events and get a 403 “over quota” error. When you hit connection limits, new connections are rejected with “over quota” errors. Resolution: Must upgrade to next plan tier. [2]

The problem: If you exceed ANY single dimension, you must upgrade your ENTIRE package—even if you’re nowhere near limits on other metrics.

Real customer experience (from Trustpilot review):

“Pusher doubled our plan because we had an increased traffic for 3 days in April” and “now they refuse to decrease our plan back to what it was, so we’re paying double for no reason” [3]

Pusher themselves acknowledge this problem in their blog post “Making it easier to outgrow usage limits”:

“Hitting your hard limits can be a frustrating experience when it happens unexpectedly” [4]

They built emergency features (3x overage allowance, automatic upgrades) specifically because customers were complaining about service disruptions.

MAU-based pricing (PubNub)

How it works: “Simple” Monthly Active User pricing that appears straightforward on the surface.

The marketing: “Simple, Transparent Pricing... based on one simple metric: Monthly Active Users. No hidden fees, no surprises.” [5]

The reality: Transaction-based metering underneath with 60+ transaction types, 2KB billing buckets, and fan-out multipliers. [6]

This trap means customers either:

Overpay because they’re not using their per user quota of transactions [7]
End up surprised by the “hidden” overage charges for transactions they were told they wouldn’t be charged for [8]

Real developer experience (Jayson Lindsley’s case study):

Told PubNub upfront he needed 3,000 active users
PubNub response: “Bundled transactions should be enough”
Result: Nearly $3,000 in unexpected overage charges
Nearly half from single operation (getMembers()) failing and retrying
Conclusion: “GetStream pays for itself - even at a higher base price”
He migrated away [8]

Consumption-based pricing (Ably, AWS, Stripe)

How it works: Pay for the resources you actually consume, measured in units that reflect value delivered.

At Ably: 3 dimensions:

Messages: The core value - the data moving between devices/people, which is what users come to Ably for.
Connection minutes: The amount of time devices are connected.
Channel minutes: The amount of time channels, used as logical streams of data, are active.

Why these dimensions: ~90% of our consumption revenue comes from messages because that’s where the value lies. If you’re delivering a game, every user move is a message. If it’s sports, every score update is a message. If it’s education, every interaction is a message. The value is in the messages, so that’s the primary billing dimension. In the same way that bandwidth is the primary billing dimension for CDNs.

No hidden complexity:

No transaction-type classifications (every update is simply a message)
No bundling that forces over-provisioning
Decoupled metrics you can optimize costs independently

AWS validates this model: The most successful cloud company in the world doesn’t bundle compute, bandwidth, storage, and observability into a single EC2 package. They charge separately for each resource because that’s what aligns with customer value and enables cost optimization.

Ably’s transparent approach

Full disclosure: We also offer MAU pricing. Some customers prefer to budget that way.

But here’s what we can tell you with certainty: Almost every customer, once they understand both models, adopts consumption-based pricing because it’s superior. We don’t force that choice—customers decide. But we’re transparent about why most of our customers choose consumption-based.

The reason is simple mathematics:

With MAU, you’re either:

Scenario 1: Quiet month → Transaction quotas unused → You overpaid for capacity
Scenario 2: Successful day → Monthly user count climbs → Surprisingly high bill because that one successful day cost you a month of usage
Scenario 3: Busy users → Transaction quota exceeded → Your budgeted MAU cost goes out the window as you pay overages for additional transactions

You can never match perfectly → You’re always in Scenario 1, 2 or 3

With consumption pricing: Quiet day = low cost. Busy day = pay for that day. Costs track actual usage patterns.

Customer optionality: We’re not here to tell customers they’re wrong about how they want to buy. But we ensure anyone who chooses MAU can switch to consumption-based at any point. And in practice, they do—because once you understand your consumption patterns, paying for what you use versus what you might use is always more efficient.