The short answer

This calculator converts fleet size, reporting frequency, payload size, QoS, downlink ratio, and an explicit overhead allowance into a planning estimate for messages per second, directional throughput, and 30-day transfer. It is useful for comparing scenarios before a packet capture or load test exists.

The output is not wire-accurate. MQTT packet length varies with topic length, properties, packet identifiers, and remaining-length encoding. TLS, TCP, IP, and radio framing add more bytes, while retransmissions and session recovery change the traffic shape. Keep the assumptions visible and replace them with measurements as the design matures.

Parameters

  • Devices is the active population represented by the scenario.
  • Messages per device per minute is the average upstream cadence. Convert event-driven bursts into a separate peak scenario rather than hiding them inside a daily average.
  • Payload bytes is the application payload before the overhead allowance.
  • QoS selects a transparent planning factor: 1.00 for QoS 0, 1.12 for QoS 1, and 1.28 for QoS 2.
  • Downlink as a percentage of uplink represents commands, acknowledgements, desired state, configuration, and other broker-to-client traffic.
  • TLS and framing overhead is a user-supplied percentage added to payload bytes before the QoS factor.

The QoS factors are not protocol constants. They are editable-by-code heuristics that keep this lightweight tool from pretending packet exchange costs are identical. For a purchase or capacity decision, replace them with captured traffic from your client, broker, topic structure, and network.

Method and formulas

Upstream message rate is:

devices × messages per device per minute ÷ 60

Estimated bytes per upstream message are:

payload bytes × (1 + overhead percentage ÷ 100) × QoS factor

Upstream throughput converts that rate to megabits per second. Downlink throughput is the chosen percentage of upstream throughput. The monthly transfer assumes the combined rate runs continuously for 30 days and uses decimal gigabytes.

Worked example

With 10,000 devices sending one 256-byte payload per minute, the upstream rate is about 166.7 messages per second. Choose QoS 1, 18% framing and TLS overhead, and downlink equal to 5% of uplink.

The planning byte count is 256 × 1.18 × 1.12, or about 338.3 bytes per upstream message. That yields roughly 0.451 Mbit/s upstream and 0.023 Mbit/s downstream. If those average rates continued without interruption for 30 days, the displayed transfer would be about 153.5 GB.

Now create a second scenario for the real peak. If devices report simultaneously on the minute or flush stored messages after reconnecting, average monthly transfer may stay similar while instantaneous throughput and broker load rise sharply. Both numbers matter, but they answer different questions.

Limitations and measurement boundary

The estimate excludes the actual topic name, MQTT fixed and variable headers, MQTT 5 properties, CONNECT and keepalive traffic, DNS, TCP establishment, TLS handshakes, certificate size, IP and link-layer headers, retransmission probability, retained delivery, offline queues, and compression. It assumes a constant rate and does not model p95 payload size or regional network quality.

Cellular and satellite billing may round sessions or packets, apply minimum increments, or price uplink and downlink differently. A byte estimate is therefore not a billing forecast. It is also not a broker capacity result: routing fan-out, persistence, authentication, and connections may constrain the broker before network throughput does.

Privacy and shareable scenarios

All arithmetic runs in this page. The six numeric or selection values are written to the current URL after calculation so a scenario can be reopened and compared. If fleet size or traffic assumptions are confidential, substitute representative values before sharing the link. No values are uploaded.

Copy creates a Markdown summary, while JSON, CSV, and Markdown downloads are assembled locally by the browser.

FAQ

Should payload size include the topic?

No. Enter only the application payload, then use the overhead percentage to represent the rest until packet captures provide a better basis.

Why is QoS 1 only a 12% factor?

It is a planning heuristic, not a claim about MQTT. Actual cost depends on packet size, acknowledgements, retransmissions, batching, and connection behavior.

Should I use average or peak frequency?

Run both. Average traffic helps estimate transfer; synchronized peaks and recovery bursts determine network and broker headroom.

Read Choosing MQTT QoS before assigning a QoS factor, especially where loss handling and application acknowledgements already exist.