A single IoT device sending occasional data over HTTP works fine. The problems show up specifically at scale, once your device count grows into the hundreds or thousands. This guide explains what actually breaks, and why MQTT was built for that problem.
In this article
Key takeaways
- HTTP is fine for a small prototype, the problems show up once your device count reaches hundreds or thousands.
- Every HTTP request opens and closes a connection, which costs real latency and battery on constrained devices at scale.
- MQTT keeps one persistent connection open and uses a publish-subscribe model, so devices don't need to know who's listening.
- MQTT handles unreliable networks directly, with delivery guarantees and a way to detect a device going offline.
Why HTTP is fine at small scale
A single IoT device sending occasional data over HTTP works fine, and for a small prototype with a handful of devices, there's no real reason to reach for anything else. The problems show up specifically at scale, once your device count grows into the hundreds or thousands.
What HTTP costs at scale
HTTP is a request-response protocol built around one client asking one server for one thing at a time. Every telemetry update opens a new connection, sends headers that are large relative to a small sensor payload, and closes the connection again.
At low device counts, that overhead is invisible. At high device counts, especially on constrained cellular or low-power connections, it adds real latency and real battery cost.
What MQTT does differently
MQTT was built for exactly this problem. It keeps a single persistent connection open and sends small, lightweight messages over it, with a publish-subscribe model that decouples devices from whatever is consuming their data.
A device publishes to a topic without needing to know who's listening, and new consumers can subscribe without the device needing any changes at all.
MQTT's advantage on unreliable networks
MQTT's other genuine advantage for IoT specifically is its handling of unreliable networks, which describes most real-world device connectivity. Quality-of-service levels let a device choose whether a message can be safely dropped or must be guaranteed delivery.
A last-will message lets the system detect a device going offline unexpectedly, rather than just silently stopping.
Which one should you use?
We recommend HTTP for occasional, low-volume telemetry from a small number of devices, and for anything that's fundamentally request-response shaped, like a device checking for a firmware update.
MQTT is worth the added setup once your system involves real device counts, constrained connectivity, or a genuine need to react to device state changes as they happen, rather than polling for them.
Common mistakes
- Reaching for MQTT too early. A small prototype with a handful of devices usually doesn't need it yet.
- Using MQTT for request-response interactions. Something like a firmware check is fundamentally request-response shaped, and HTTP fits it fine.
- Ignoring battery cost at scale. Constrained cellular or low-power connections feel the cost of repeated HTTP connections most.
- Polling for state changes instead of subscribing to them. Once you have real device counts, this is exactly the problem MQTT's publish-subscribe model solves.
FAQ
Is HTTP ever fine for IoT devices?
Yes, for a small prototype, occasional low-volume telemetry, or anything fundamentally request-response shaped, like a firmware check.
What's the main technical difference between HTTP and MQTT?
HTTP opens and closes a new connection for every request. MQTT keeps one persistent connection open and uses publish-subscribe messaging.
When is MQTT worth the added setup?
Once your system involves real device counts, constrained connectivity, or a need to react to device state changes as they happen.
The bottom line
HTTP is fine until your device count grows. MQTT exists specifically for what breaks after that: connection overhead, battery cost, and unreliable networks. Choose based on your system's actual shape, not which protocol sounds more modern.
Designing a telemetry system for a growing fleet of devices? Talk to our team.
