MQTT vs HTTP for IoT at Scale: Benchmarks from the Field

MQTT (Message Queuing Telemetry Transport) is a publish-subscribe messaging protocol designed for constrained devices and low-bandwidth networks. It maintains a persistent TCP connection between client and broker.

HTTP (typically REST over HTTPS) is the request-response protocol that powers the web. Each interaction opens a connection, sends data, receives a response, and closes the connection.

The fundamental difference: MQTT maintains state (the connection), HTTP doesn't. This single distinction cascades into every performance metric.

These benchmarks come from three production deployments we manage:

• ▹Deployment A: 5,200 environmental sensors in a smart building complex, reporting temperature/humidity every 30 seconds
• ▹Deployment B: 18,000 asset trackers in a logistics network, reporting GPS coordinates every 60 seconds
• ▹Deployment C: 52,000 industrial vibration sensors in a manufacturing facility, reporting frequency-domain features every 5 seconds

For a single sensor reading (temperature + humidity + device ID + timestamp), here's the wire-level comparison:

At Deployment C's scale (52,000 sensors × 12 messages/minute), that's the difference between 31 MB/min (MQTT) and 624 MB/min (HTTP). Over a month: 1.3 TB vs 26 TB. The bandwidth cost difference alone is significant, but the real impact is on your broker/server infrastructure sizing.

Average end-to-end latency (device → cloud processing → acknowledgment):

MQTT's persistent connection eliminates TCP handshake and TLS negotiation on every message. At small scale, the difference (66ms) is irrelevant for most applications. At 52K devices, HTTP's 380ms average latency includes connection pool exhaustion events that spike to 2-3 seconds — unacceptable for real-time monitoring.

This is where MQTT's QoS (Quality of Service) levels become critical:

• ▹QoS 0: Fire and forget. Similar to UDP — fast but no delivery guarantee.
• ▹QoS 1: At least once delivery. The broker acknowledges receipt. Messages may be duplicated but never lost.
• ▹QoS 2: Exactly once delivery. Four-step handshake ensures no duplicates and no losses.

In Deployment B (logistics), devices frequently go through cellular dead zones. MQTT with QoS 1 handles this natively: the client queues messages during disconnection and delivers them when connectivity returns. With HTTP, we had to build an entire offline queuing system on the device — roughly 2,000 lines of code that MQTT gives you for free.

Packet loss rates during degraded connectivity: - MQTT QoS 1: 0.001% (only during broker failovers) - HTTP with retry logic: 0.3% (timeouts that exhaust retry budget)

Despite MQTT's advantages at scale, HTTP is the right choice in specific scenarios:

• ▹Low-frequency reporting (once per hour or less) — The connection overhead is amortized, and HTTP's simplicity wins.
• ▹Request-response patterns — Device needs to query the server for configuration. MQTT can do this (request-response pattern over pub/sub) but it's clunky.
• ▹Firewall-constrained environments — Some corporate networks block non-HTTP traffic. MQTT over WebSockets is an option, but adds complexity.
• ▹Simple integrations — If you're connecting to a third-party API that only speaks HTTP, don't add an MQTT broker just for the sake of it.

For any IoT deployment above 1,000 devices with reporting intervals under 5 minutes:

• ▹Use MQTT as the primary device-to-cloud protocol
• ▹Use HTTP for device configuration and firmware updates
• ▹Use MQTT over WebSockets when firewall traversal is needed
• ▹Deploy a clustered broker (we use EMQX or HiveMQ) — single-instance brokers become a bottleneck around 20K concurrent connections
• ▹Plan for QoS 1 as the default — QoS 2 doubles the message count and is rarely necessary

The protocol choice is one of those decisions that's easy to get right at the start and incredibly expensive to change later. If you're planning an IoT deployment and want to get the architecture right from day one — that's exactly what we do.