MQTT vs HTTPS for Device Ingestion
Choosing an ingestion protocol is a tradeoff between battery, latency, intermittency, and the operational reality of running a broker. A pragmatic comparison.
“MQTT or HTTPS?” is rarely a protocol question. It’s a question about power budgets, network reliability, message semantics, and which team has to operate the broker at 3am. The right call depends less on the spec sheet and more on the constraints your devices actually live under.
This is a placeholder article outlining the comparison.
The honest tradeoff
| Concern | MQTT | HTTPS |
|---|---|---|
| Battery / overhead | Lower, persistent connection | Higher per-request |
| Intermittent links | Strong (QoS, retained messages) | Retry logic on you |
| Restrictive networks | Sometimes blocked | Usually allowed |
| Operational burden | Broker to run and secure | Stateless, familiar |
When MQTT wins
Battery-constrained sensors, lossy links, and telemetry that benefits from pub/sub fan-out. The persistent connection and QoS levels do real work here.
When HTTPS wins
Devices that report infrequently, environments where outbound 443 is the only reliable path, and teams who would rather not operate a broker. Request/response also maps cleanly onto existing API gateways and auth.
The constraints that actually decide it
- How much power and bandwidth each message can cost.
- Whether the network allows persistent connections at all.
- Whether you need store-and-forward when a device is offline for hours.
- Who owns broker operations once you’re past the prototype.
The right answer is usually “both, by device class” — and a clear policy for which class a new device belongs to.