MQTT Message Rate Calculator

MQTT Message Rate Calculator

Estimate MQTT messages per second, payload plus protocol overhead bandwidth, QoS acknowledgement traffic, broker CPU/RAM needs, retained message storage, and peak burst headroom for smart home automation brokers.

MQTT presetsCommon smart home broker loads
InputsMsg/sec = devices x topics x publish rate
Sensors, bridges, cameras, and controllers that publish.
Average active publish topics per device.
The calculator converts this to messages per second.
JSON, binary, or text payload size.
Fixed header, topic name, packet id when used.
Average broker deliveries per published message.
Reconnects, automations, discovery, and polling bursts.
TCP/IP, TLS record, bridge, and framing allowance.
Mosquitto and small brokers often start low, integrations add more.
Message rate 0 msg/s Peak 0 msg/s
Payload bandwidth 0 Mbps Payload plus overhead
Broker estimate 0 core 0 MB RAM
Retained storage 0 MB QoS multiplier 1x
Enter MQTT settings to estimate broker load.
Protocol formula gridCore MQTT sizing assumptions
D x T x R
Message rate

Devices multiplied by active topics and publish rate per topic.

P + O
Bytes per packet

Payload bytes plus MQTT topic/header overhead bytes.

1x / 2x / 4x
QoS packet flow

QoS 0 publish, QoS 1 publish plus ack, QoS 2 four packet handshake.

Retain x size
Storage

Retained message count multiplied by retained payload plus metadata.

Reference tablesQoS, payloads, and broker capacity

MQTT QoS protocol table

QoS levelProtocol exchangeAck multiplierSmart home fit
QoS 0PUBLISH only, no delivery acknowledgement1x packet flowFrequent telemetry where one missed value is acceptable.
QoS 1PUBLISH plus PUBACK2x packet flowCommands, switch states, and important automation events.
QoS 2PUBLISH, PUBREC, PUBREL, PUBCOMP4x packet flowRare critical actions where duplicate handling matters.
RetainLatest message kept by the brokerStorage copyDevice availability, discovery, and current state topics.

Typical smart home payload sizes

Message typePayload bytesMQTT overheadNotes
Binary contact8-40 B20-45 BShort topic and small ON/OFF value.
Sensor JSON80-250 B25-70 BTemperature, humidity, battery, and units.
Discovery config400-1200 B40-120 BLarge retained configuration documents.
Event metadata250-900 B35-100 BCamera or presence event data without the image.

Broker host planning ranges

Host classComfort rangeCPU model usedRAM planning note
Pi Zero / tiny SBC50-150 msg/s0.015 core per 100 msg/sKeep retained state small.
Raspberry Pi 4300-800 msg/s0.010 core per 100 msg/sGood for typical homes.
NAS container1000-3000 msg/s0.007 core per 100 msg/sWatch container memory limits.
Home server VM3000+ msg/s0.005 core per 100 msg/sUsually network or logging limited first.

Preset sizing examples

ScenarioDevicesRate patternLikely bottleneck
Small home35State every 5 minNone, retained cleanup matters.
Energy meters16Many 1 sec topicsMessage count and database ingest.
Discovery burst90Reconnect stormRetained config and burst CPU.
Fleet stress400Telemetry every 2 secBroker fanout, logging, and storage.
Formula check: Message rate uses devices x topics x publish rate. Bandwidth uses message rate x (payload + MQTT overhead), then applies QoS, fanout, burst, and network overhead.
Retained state: Retained storage is small for simple states but can grow quickly when discovery payloads, JSON attributes, and many availability topics are retained.

You begin by installing one motion sensor in your hallway which is fine. Next you install a smart thermostat. You also installs some door locks, climate controls and lights.

Your home automation hub begins to feel sluggish. Commands takes seconds to register. The interface lag. Something seems wrong with the network, you think, except what’s really wrong is probable much more specific. It’s the invisible traffic: MQTT messages overwhelming your broker. Use this tool to see that traffic before it chokes your system.

Why Your Home Network Gets Slow

So MQTT is lightweight. That’s its selling point. But lightweight isn’t the same thing than weightless. Every command sent, every state change, every sensor reading create a packet. Each packet has an identifier, a topic name and some kind of header. Most reliable home setups sends with QoS level one, which means each publish get an acknowledgement back from broker, double the number of packets being passed around. Level two is used for critical safety commands and quadruples the number. The calculator above will do the math for you when you input how many device you have and how often messages are generated. It saves you from guessing at coefficients and conversion factors; you simply need to know what all that stuff represent in your own living room.

A temp reading might feel like a tiny amount of data, but most people vastly underestimate how large payloads can be. Two hundred bytes isn’t hard to imagine once you’ve wrapped it all in JSON with time stamps, device IDs, and unit labels. With thirty devices each sending once a minute, you’re pumping out several kilobytes per second which isn’t terrible. If a zigbee bridge holds the state for fifty different sensors, you are using megabytes of ram to store latest state of your lights. The only problem is retained messages don’t automatically expire; they sits in memory till they get overwritten or deleted.

A lot of Raspberry Pi based systems runs into this. While the cpu will be fine, the ram gets filled up with old configuration information from long forgotten devices. A Raspberry Pi Zero is charming, but it’s not a server. A single core with limited memory will do a beautiful job handling a dozen sensor, but not a hundred. It knows this because the calculator factors in the type of host you use when adjusting its estimates. A dedicated home server have more headroom per message than a Pi Zero does.

It also takes into account burst traffic: networks aren’t smooth and devices reconnect, which means there are going to be spikes in traffic five or ten times above average. You know what creates those? Discovery protocols scan for new gear, and automations trigger cascades of updates. These events cause much higher traffic spikes than usual. If your average load is at eighty percent capacity, then that burst is going to push you up to a hundred and that’s where things start breaking.

What does this mean? The tool has a quality of service table that you can check out to see what they means. Fire and forget (level 0) is going to be fast but will never guarantee delivery. Level one does guarantee delivery but doesn’t have the heavy handshake of level two, which is why it’s typical the sweet spot for home automation. Finally, if you’re doing something where lost commands or duplicates are unacceptable (like disarming your security system), then you want level two. Using level two everywhere protect you from mistakes, but it is slow and difficult to use. So pick your QoS based off the consequences of failure… Not solely for peace of mind.

Local networks don’t often have bandwidth as the bottleneck; kilobit MQTT over gigabit Ethernet or WiFi is no problem. Instead, the limits are typical the CPU and RAM, which the calculator provides an estimate for (in terms of megabytes and cores). This isn’t exact, but it’s a guide, use it to see whether the calculator thinks your Pi 4 might be overloaded, in which case you can either archive old retained messages or move the broker to a beefier machine.

Debugging is harder than planning so plan ahead, respect the overhead, and give your broker some breathing room. The numbers will tell you what to do, but where to draw the lines is up to you. You should of checked this earlier.

MQTT Message Rate Calculator

Leave a Comment