Almost every IoT cloud platform lets devices connect over both MQTT and HTTP, and that is exactly why teams pick one by habit instead of by need. The choice shapes battery life, how you send commands back to devices, and how painful your first real outage is. It is worth an hour of thought before you write firmware around it.

What You Are Actually Choosing Between

HTTP is request and response. A device opens a connection, sends a payload, gets an answer, and usually closes the connection. Everything your web stack already understands, such as load balancers, proxies, logging and authentication headers, works without special effort.

MQTT is publish and subscribe over a long-lived connection. The device connects to a broker, announces what it will publish, and subscribes to topics it wants to hear about. The broker routes messages. The connection stays open, so the cloud can push to the device without the device asking first.

That last point is the real dividing line. If your devices only ever send data upward and never need to be told anything, the two protocols are closer than the internet arguments suggest. The moment the cloud must reach the device, MQTT starts to earn its place.

Where HTTP Is the Better Fit

HTTP wins when devices wake rarely, send a batch, and go back to sleep. A sensor that reports once an hour gains little from holding a connection open, and some constrained networks make keeping one alive expensive or unreliable. Each report is a self-contained transaction that is easy to retry and easy to debug with ordinary tools.

It also wins when the device has to traverse awkward networks. Corporate firewalls and some cellular carriers handle outbound HTTPS without any special rules, while MQTT ports sometimes need an exception someone has to request.

Finally, HTTP is the lower-effort choice when your team already runs web services and has no one who has operated a broker. Operational familiarity is a legitimate engineering factor.

Where MQTT Is the Better Fit

MQTT wins when devices need commands, configuration changes or firmware notifications delivered promptly. With HTTP, the only way to get a command to a device is for the device to poll, which trades latency against wasted requests. With MQTT, the subscription is already open.

It also helps with chatty fleets. Per-message overhead is small, and the protocol has built-in delivery levels so you can choose between fire-and-forget and acknowledged delivery per message. Many platforms also build device presence, shadows or twins and rules engines on top of MQTT topics, so using it often unlocks platform features you would otherwise reimplement.

In practice, the deciding question is rarely throughput. It is: how does a command reach a device on a bad day?

A Side-by-Side View

Concern	HTTP	MQTT
Connection model	Short-lived request and response	Long-lived session through a broker
Cloud-to-device messages	Device must poll	Pushed over existing subscription
Sleepy, infrequent reporters	Natural fit	Reconnect cost on each wake
Firewall friendliness	Usually simple	May need port or proxy work
Delivery guarantees	You build retries and idempotency	Quality-of-service levels built in
Debugging	Familiar web tooling	Needs broker logs and an MQTT client
Platform-specific features	Often limited	Often richer (presence, twins, rules)

Check your platform’s current documentation, because which features attach to which protocol varies between providers.

A Hypothetical Example

Imagine a fleet of soil sensors in remote fields that wake once every few hours, take readings, and send them. They run on batteries and use a cellular modem that costs power every time it attaches to the network. The team starts with MQTT because the platform tutorial uses it, then finds that most of each wake cycle is spent establishing the session.

Switching the reporting path to a single HTTPS request per wake, with the readings batched, cuts the time the radio is on. But they also want to change the sampling interval remotely. Their answer is to have the device ask for pending configuration in the response to each report. Commands are delayed by up to one wake cycle, which is acceptable for soil moisture. For a door lock, it would not be.

Mistakes That Show Up Later

A common trap is assuming MQTT quality-of-service settings make your pipeline reliable end to end. They describe delivery between two points, not whether your downstream processing succeeded. Design for duplicates and reordering regardless of protocol.

Another is skipping client identifiers and session behavior. If two devices accidentally share an identifier, brokers typically disconnect one to admit the other, and the pair will fight each other in a reconnect loop that looks like a network problem.

A third is forgetting that long-lived connections need keepalive tuning. Mobile networks and NAT devices silently drop idle sessions, and a device that thinks it is connected while the broker has forgotten it will publish into the void.

Making the Decision

Write down three things before choosing: how often each device reports, whether the cloud ever needs to send something unprompted, and what the network between device and cloud looks like. If the answers are “rarely”, “no” and “restrictive”, start with HTTP. If they are “often”, “yes” and “mobile or unstable”, MQTT is likely worth the extra moving parts. Mixed fleets are normal, and many platforms accept both, so you can pick per device class rather than for everything.

Frequently Asked Questions

Can one fleet use both MQTT and HTTP? Yes. Many platforms ingest both into the same pipeline, and it is common to use HTTP for sleepy battery devices and MQTT for always-powered ones. Keep the message schema identical so downstream processing does not care which path a reading took.

Is MQTT always more efficient than HTTP? Not always. It is efficient once a session is established, but for devices that connect rarely, session setup can dominate. Measure on your real hardware and network rather than assuming.

Do I need to run my own MQTT broker? Usually not at first. Most IoT cloud platforms provide a managed broker endpoint. Running your own makes sense only when you have requirements the managed option cannot meet and the people to operate it.

How do I secure either protocol? Use TLS for transport and per-device credentials, such as certificates, rather than a shared secret baked into every unit. Specifics differ by platform, so follow its current security documentation.

What if my devices are too constrained for TLS? Revisit the hardware choice or place a gateway between the devices and the cloud that terminates a secure connection on their behalf. Sending unprotected data over the public internet is hard to justify.

Next Step

Pick your two most awkward device classes, perhaps the one that sleeps longest and the one that needs commands soonest, and prototype both protocols against your platform’s test endpoint. Measure radio-on time and command latency on real hardware, then decide.