MQTT or HTTP for Device Telemetry: What Actually Decides It
The choice is usually made on habit rather than on constraints. How connection model, payload overhead, battery cost and delivery guarantees really differ, and when plain HTTP is the better answer.
The default advice is that MQTT is for devices and HTTP is for everything else, which is true often enough to be misleading. Both move telemetry perfectly well. The differences that matter are in the connection model, and they only become visible at the scale and power budget a real deployment runs at.
HTTP is request-response over a connection that is typically opened, used and closed. Every message pays for that setup, and on TLS the handshake is the expensive part: several round trips before a single byte of telemetry moves. For a device reporting once an hour, this is irrelevant. For a device reporting every ten seconds, the handshake can dominate both the airtime and the energy budget, and on a battery-powered cellular device it is the difference between months and weeks of life.
MQTT keeps one connection open and pushes messages through it. The setup cost is paid once, and each subsequent publish carries a header measured in single-digit bytes rather than the hundreds an HTTP request spends on headers. It also makes the server able to reach the device, which HTTP cannot do without polling. If the deployment needs commands to arrive promptly at devices behind NAT, that alone usually settles the question.
The persistent connection is not free, though, and this is the part that gets underweighted. It has to be kept alive, which means periodic keepalive traffic even when nothing is happening, and on a mobile network every keepalive wakes the radio. It also means the server holds state for every connected device, so a hundred thousand devices is a hundred thousand open sockets to plan capacity around. HTTP's statelessness, which looks like a weakness at the device, is what makes it trivially horizontally scalable at the server.
Delivery guarantees are where MQTT earns its reputation. Its quality-of-service levels let a device request at-most-once, at-least-once or exactly-once delivery, and the broker handles retries and deduplication. Getting the equivalent over HTTP means implementing retry logic, idempotency keys and backoff in the client, on the device, in firmware that is harder to update than anything else in the stack. That is achievable but it is work, and it is work that has to be right.
The honest decision procedure is short. If devices report infrequently, are mains-powered, and never need to be commanded in near real time, HTTP is simpler to operate, easier to debug, and passes through every proxy and firewall in existence without special handling. If they are battery-powered, report often, sit behind NAT, or need reliable command delivery, MQTT repays its added operational complexity quickly. The mistake worth avoiding is choosing on familiarity and discovering the constraint after the firmware is in the field, where changing it is the most expensive kind of change there is.