MQTT broker pricing is confusing mainly because vendors measure different things: one bills per connection, another per message, a third per gigabyte, and a fourth per dedicated cluster. This guide explains each pricing model, shows which workloads it favours or penalises, and gives you a repeatable method to estimate your own usage so you can compare quotes on equal terms. It deliberately contains no price figures, because those change often; the method stays valid.
Why MQTT Broker Pricing Varies So Much
A broker's real costs come from a few resources: memory per open connection, CPU per message routed, network bandwidth, storage for retained and queued messages, and the people who operate it. Each vendor picks one or two of these as the billing unit and bundles the rest into plan limits. As a result, two services can look cheap or expensive for exactly the same fleet depending on your traffic shape.
Consider two fleets. The first has many thousands of devices that each send a small reading every fifteen minutes. The second has a few dozen machines streaming high-frequency data. The first is connection-heavy and message-light; the second is the opposite. A per-connection model favours the second fleet, a per-message model favours the first. Knowing your shape is the whole game.
The Common MQTT Broker Pricing Models
1. Per Connection
You pay for the number of concurrent connections, often measured as a peak or as a monthly maximum. Message volume may be unlimited within fair use or capped per plan.
- Favours: chatty devices, high message rates, small fleets.
- Penalises: huge fleets of mostly idle devices, and architectures where every browser tab or mobile app holds its own connection.
- Watch for: whether the count is concurrent or cumulative, and whether short reconnect storms count against the peak.
2. Per Connection-Minute (Session Time)
You pay for the total time clients stay connected, typically counted in connection-minutes or session-minutes. It is common in cloud IoT platforms that bill everything as consumption.
- Favours: devices that connect briefly, publish and disconnect.
- Penalises: always-connected devices, which accumulate a full month of minutes each.
- Watch for: how fractions of minutes are rounded, and whether keepalive traffic counts as messages too.
3. Per Message
You pay per message published or delivered, often in blocks. Some services count a message once on publish; others count each delivery to each subscriber, so one publish with ten subscribers counts as eleven. Some count in fixed-size increments, so a large payload counts as several messages.
- Favours: large, quiet fleets.
- Penalises: high-frequency telemetry, fan-out to many subscribers and large payloads.
- Watch for: whether pings, subscribes, retained deliveries and QoS acknowledgements are counted.
4. Per Traffic Volume
You pay per gigabyte transferred in, out or both. This is close to how cloud networking is billed.
- Favours: compact binary payloads such as Sparkplug B or CBOR.
- Penalises: verbose JSON, high fan-out and video-like workloads.
- Watch for: whether TLS and protocol overhead are included, and whether ingress and egress are priced differently.
5. Tiered Plans with Quotas
You pay a fixed amount per tier, and each tier includes limits on connections, message size, QoS level, throughput or features. This is the most predictable model for budgeting.
- Favours: teams that want a known monthly bill.
- Penalises: workloads that sit just above a tier boundary.
- Watch for: what happens at the limit: rejection, throttling or automatic overage billing.
6. Dedicated Capacity
You pay for an isolated cluster sized in instances, nodes or capacity units, regardless of how much you use it. BYOC (bring your own cloud) is a variant in which the infrastructure runs in your own cloud account, so you pay the cloud provider for resources and the vendor for management.
- Favours: large, steady workloads, strict isolation and data residency needs.
- Penalises: small or spiky workloads that leave capacity idle.
- Watch for: minimum commitments, high-availability multipliers and who pays for cross-zone traffic.
7. Self-Managed Licences
For software you operate yourself, vendors may charge per node, per core, per connection tier or by enterprise agreement. The licence is only part of the cost; infrastructure and staff time often dominate. Our MQTT broker total cost of ownership guide covers those hidden costs.
Pricing Models at a Glance
| Model | Billing unit | Best for | Biggest risk |
|---|---|---|---|
| Per connection | Concurrent clients | Few, busy clients | Large idle fleets |
| Connection-minutes | Time connected | Intermittent devices | Always-on devices |
| Per message | Messages published or delivered | Large quiet fleets | Fan-out and high rates |
| Per traffic | Gigabytes | Compact payloads | Verbose JSON, fan-out |
| Tiered plans | Fixed per tier with quotas | Predictable budgets | Tier boundaries |
| Dedicated capacity | Cluster size | Large steady load, isolation | Idle capacity |
| Self-managed licence | Nodes, cores or agreement | Full control | Hidden operations cost |
How to Estimate Your Usage
Before comparing any quotes, measure or estimate your workload. Every pricing model can be calculated from the same handful of numbers:
- Devices (D): number of publishing clients.
- Other clients (B): backends, dashboards, browser sessions, Node-RED instances.
- Peak concurrent connections: usually D + B, plus headroom for reconnect overlap.
- Messages per device per hour (R).
- Average payload size in bytes (S).
- Average subscribers per message (F): fan-out.
- Connected fraction of time (C): 1.0 for always-on devices.
From these, derive monthly figures (using 730 hours per month):
published messages / month = D x R x 730
delivered messages / month = published x F
connection-minutes / month = (D + B) x C x 730 x 60
payload traffic in (bytes) = published x S
payload traffic out (bytes) = delivered x S
A worked example with assumed numbers: 400 devices publishing every 30 seconds (R = 120), a 200-byte JSON payload and two subscribers per message (a database writer and a dashboard).
published = 400 x 120 x 730 = 35,040,000 messages / month
delivered = 35,040,000 x 2 = 70,080,000 messages / month
traffic in = 35,040,000 x 200 bytes = about 7 GB / month
traffic out= 70,080,000 x 200 bytes = about 14 GB / month
peak connections = 400 + 3 backend clients + headroom
Apply each vendor's units to these figures, then add protocol overhead (TLS, MQTT headers, keepalives) of a few tens of percent to traffic estimates rather than assuming payload bytes are the whole story. A pilot on a real broker, observed through its console or $SYS statistics, lets you replace assumptions with measured values during a pilot.
Cost Levers You Control
Whatever the model, you can usually lower the bill with design choices:
- Publish on change or with deadbands instead of fixed fast intervals.
- Batch several readings into one message where latency allows.
- Use compact payloads or MQTT 5 topic aliases to cut bytes.
- Use shared subscriptions instead of many identical consumers.
- Avoid one broker connection per browser tab when a backend can fan out.
Mapping Your Estimate to ConnectMQ Plans
ConnectMQ uses tiered plans defined by limits, which keeps estimation simple: find the smallest plan whose limits cover your peak connections, QoS and message size. Serverless (Free) runs on a shared cluster with up to 25 connections, QoS up to 1 and 256 KB messages, which suits prototypes and small pilots. Serverless (Paid) raises that to up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions. Beyond that, Dedicated provides an isolated cluster, BYOC runs in your own cloud account managed by ConnectMQ, and Self Managed Enterprise runs on your infrastructure. When a quota is reached, MQTT 5 clients receive a clear reason code such as 0x97 (quota exceeded), so limits never fail silently. The MQTT broker connection quotas article explains how to plan around them.
Compare Plans on ConnectMQ
Start on the free Serverless plan at app.connectmq.com with no credit card, measure your real traffic during a pilot, and move up only when the numbers say so. ConnectMQ is a managed MQTT broker with the same endpoints and client code on every plan. For context on deployment models, read our cloud MQTT broker guide, and see MQTT broker free tier for what to expect from free plans across the market.
Frequently Asked Questions
Which MQTT broker pricing model is cheapest?
None is cheapest in general. Per-connection pricing suits a few busy clients, per-message pricing suits many quiet devices, and dedicated capacity suits large steady loads. Estimate your workload first, then apply each model.
Do keepalive pings count as messages?
It depends on the vendor. Some count only application publishes, others count all MQTT packets. Ask explicitly, because short keepalive intervals on a large fleet can add up.
How do I avoid surprise overage charges?
Choose a plan whose limits reject or throttle rather than bill automatically, monitor usage in the console, and set alerts before you approach a quota.
Can I estimate costs without real devices?
Yes, using the formula in this guide with assumed rates and payload sizes. Replace the assumptions with measured values from a small pilot as soon as you can.
