MQTT Broker Sizing Calculator

QoS 0 (fire-and-forget) counts each publish once. QoS 1 (at-least-once) doubles effective traffic because every publish requires a PUBACK response. QoS 2 (exactly-once) quadruples it because it needs the full four-message handshake — PUBLISH, PUBREC, PUBREL, PUBCOMP — to guarantee exactly-once delivery. The calculator applies this multiplier directly to your ingest rate before computing bandwidth.

Fan-out is estimated as total subscriptions (clients times average subscriptions per client) divided by topic count — essentially, how many subscribers on average share each topic. It's capped at the total client count because a single published message can never physically be delivered to more clients than exist in the deployment, no matter how the subscription math works out.

Every message gets roughly 25 bytes of MQTT framing (fixed header, topic name, and packet ID) plus a 29-byte TLS record header, for about 54 bytes of overhead on top of your stated average payload. On a deployment with many small payloads, like a 4-byte temperature reading, this overhead can dominate total bandwidth rather than being a rounding error.

The 50,000-delivered-messages-per-second-per-core benchmark assumes a well-tuned broker like EMQX or VerneMQ under typical conditions. Real throughput varies with hardware, whether TLS termination happens on the broker itself, and persistence settings — a broker doing heavy disk-backed QoS 1/2 persistence or terminating TLS in software will need more cores than this estimate suggests.

QoS 0 messages are fire-and-forget with no retry, so the broker doesn't need to hold them in memory after delivery. QoS 1 and 2 require store-and-forward semantics to guarantee delivery, so the calculator adds a buffer sized for roughly 5 seconds of in-flight messages at your effective message rate and payload size — this buffer is skipped entirely when QoS is set to 0.