Should I Use MQTT or HTTP for My IoT Device?

Why the MQTT vs HTTP Decision Is Harder Than It Looks

Most teams treat the question of whether to use MQTT or HTTP for their IoT device as a simple one. MQTT is for IoT. HTTP is for web apps. Pick one and move on.

That mental model is wrong, and it costs teams real time. The right answer depends on three things that vary significantly between IoT products:

How often does the device send data? A temperature sensor sending one reading every 5 minutes behaves very differently from a vibration monitor streaming 200 samples per second. The first barely notices the difference between MQTT and HTTP. The second will fail under HTTP.

Does the device need to receive commands from the backend? HTTP is fundamentally a request-response protocol. The device asks, the server answers. If the server needs to push a command to the device - change a setting, trigger an action, cancel a session. HTTP requires the device to poll continuously or implement a separate WebSocket channel. MQTT handles bidirectional communication natively over a single persistent connection.

What does the network look like in the field? A device on a reliable Wi-Fi connection behaves differently from a device on cellular in a location with intermittent coverage. HTTP requires a complete connection for every message. MQTT maintains a persistent connection with automatic reconnection logic and a last-will message that tells the broker what to do if the device disappears.

Getting the MQTT vs HTTP decision wrong does not just produce a suboptimal system. It produces a system that needs to be rebuilt at the backend layer after the firmware is already in production. That means a firmware update campaign, a backend migration, and a period where the two are out of sync.

What HTTP Gets Right for IoT and Where It Falls Apart

HTTP is not a bad protocol for IoT. For a specific class of IoT device, it is the right choice. The problem is that teams use it for device types it was never designed for.

Where HTTP works well:

HTTP is the right protocol when the device sends data infrequently, the server never needs to push commands to the device, and the network is stable enough to complete a full TCP handshake on every message. A device that reads a sensor once per minute and sends the value to a REST API endpoint fits this profile exactly.

HTTP also wins on tooling. Every developer knows how to build a REST API. Every cloud platform has native HTTP endpoint support. Debugging an HTTP request is trivial: open the network inspector, read the payload, check the status code. The ecosystem is mature, the documentation is everywhere, and the learning curve is flat.

Where HTTP breaks down:

The cost of HTTP is connection overhead. Every request requires a TCP connection, a TLS handshake, HTTP headers, and a response. For a device sending 10 readings per second, this overhead dominates the payload. The device is spending more time on connection setup than on data transfer.

On a battery-powered device, that connection overhead draws radio power. More connection events per minute means more radio-on time. More radio-on time means faster battery drain. A device that should last 6 months on a single battery may last 8 weeks because the HTTP polling cycle never lets the radio sleep long enough.

HTTP also has no concept of connection state. If the network drops mid-request, the message is lost. No built-in retry. No acknowledgement. No message queuing. The firmware has to implement all of this manually - which most teams do not, until a message loss incident in production forces the issue.

What MQTT Gets Right for IoT and Where It Adds Complexity

MQTT was designed in 1999 for oil pipeline monitoring: remote sensors on unreliable satellite connections that needed to send data reliably with minimal bandwidth. That problem is nearly identical to modern IoT. The protocol has aged better than almost anything else in the stack.

Where MQTT wins:

MQTT uses a publish-subscribe model. The device connects to a broker once and maintains that connection. To send data, it publishes a message to a topic. To receive commands, it subscribes to a topic. The single persistent connection handles both directions. The radio does not need to reconnect for every message.

For a battery-powered device, this is significant. The MQTT connection handshake happens once at startup. Every subsequent message is just a publish: minimal overhead, minimal radio-on time. A device sending data every 30 seconds with MQTT can achieve average radio duty cycles below 1% of the active time. The same device over HTTP might reach 20% because of the connection overhead on every request.

MQTT also includes three quality-of-service levels that let you choose the delivery guarantee for each message:

• QoS 0: fire and forget. Message sent once, no acknowledgement. Lowest overhead. Acceptable for non-critical telemetry where occasional loss is fine.

• QoS 1: at least once. Message delivered and acknowledged. May produce duplicates on retry. Right for most sensor data.

• QoS 2: exactly once. Two-step handshake guarantees single delivery. Highest overhead. Right for commands or billing-critical events.

Where MQTT adds complexity:

MQTT requires a broker. The broker is a piece of infrastructure that must be deployed, configured, monitored, and scaled. Mosquitto runs on a $5 VPS for a pilot. It becomes a bottleneck at 10,000 concurrent connections unless configured correctly. AWS IoT Core, HiveMQ, and EMQX are managed broker options that remove the operational burden but add cost.

MQTT debugging is also less intuitive than HTTP. There is no request-response structure. Messages flow asynchronously. A message that disappears did not produce an HTTP 500. It just did not arrive. Tracing a missing message requires broker-level logging and a topic monitor. Teams unfamiliar with pub-sub architecture find the first few weeks of MQTT debugging disorienting.

The Reconnection Problem - Where Most Teams Get Hurt

The decision between MQTT and HTTP is not just about data volume or battery life. It is about what happens when the network drops, which it will, in any real deployment.

HTTP has no reconnection concept. A request in flight when the network drops fails. The firmware must detect the failure, implement a retry strategy, and decide how to handle data accumulated during the outage. Most teams implement a naive retry that hammers the endpoint as soon as connectivity returns. When many devices lose connectivity simultaneously (a site-wide Wi-Fi outage, a cellular tower issue, a cloud region going down), the reconnection storm takes down the backend that handles individual connections perfectly.

MQTT handles reconnection natively in the broker and the client library. The device reconnects to the broker, re-establishes subscriptions, and delivers any messages queued during the outage. The broker can buffer messages for offline devices if persistent sessions are configured. The client library handles exponential backoff automatically in most production-grade implementations.

More importantly, MQTT's last-will mechanism solves a problem HTTP cannot touch at all. When a device connects, it registers a last-will message with the broker. If the device disconnects unexpectedly (power failure, network drop, firmware crash), the broker publishes the last-will message to a monitoring topic. The backend immediately knows the device went offline uncleanly. With HTTP, that event is invisible until the device fails to send its next scheduled reading.

On one industrial monitoring project, a batch of 80 devices on a factory floor went offline simultaneously during a switch maintenance window. With MQTT last-will configured, the backend received 80 offline notifications within 30 seconds of the event. The operations team was alerted before anyone noticed the monitoring gap. Without MQTT, the system would have been silent until the next polling cycle — 5 minutes later and the alerts would have arrived without a clear cause.

How to Decide: MQTT or HTTP for Your Device

Answer these five questions before picking a protocol for your IoT device. Each one narrows the choice.

Question 1: How often does the device send data?

Under 1 message per minute: HTTP is viable. Over 1 message per minute: MQTT's lower per-message overhead starts to matter. Over 10 messages per minute: MQTT is the clear choice.

Question 2: Does the backend ever need to push commands to the device?

Never: HTTP works fine for one-direction reporting. Sometimes: add a polling loop in firmware and accept the overhead. Regularly: MQTT is the right architecture because a persistent bidirectional connection costs less than any polling strategy.

Question 3: Is the device battery-powered?

No, mains powered: protocol choice has lower power consequences, use whichever fits the backend better. Yes, battery-powered: MQTT's persistent connection reduces radio-on time significantly. For coin-cell devices targeting months or years of battery life, HTTP polling is almost always disqualifying.

Question 4: Is the network reliable in the deployment environment?

Reliable Wi-Fi, predictable connectivity: HTTP is manageable with a retry strategy. Cellular, industrial environments, outdoor deployments with intermittent coverage: MQTT's reconnection handling and offline message queuing matter significantly.

Question 5: Does the team have MQTT infrastructure experience?

Yes or can acquire it: proceed with MQTT. No and timeline is tight: consider a managed broker (AWS IoT Core, HiveMQ Cloud) to remove the operational burden before evaluating the protocol itself.

Frequently Asked Questions

Can I use both MQTT and HTTP in the same IoT system?

Yes, and many production systems do. A common pattern: devices use MQTT for real-time telemetry and command delivery, and the backend exposes HTTP endpoints for the dashboard, mobile app, and third-party integrations. The broker handles device-side communication. The REST API handles application-side communication. The two layers never talk directly. The backend subscribes to MQTT topics and writes to a database that the HTTP API reads from.

Does MQTT work over cellular for IoT devices?

MQTT is well-suited to cellular because its persistent connection and keep-alive mechanism handle the intermittent connectivity that cellular deployments produce. Configure the MQTT keep-alive interval to match the cellular network's session timeout (typically 60 to 300 seconds depending on the carrier). Use QoS 1 for messages that must survive a reconnection, and implement an offline buffer in firmware for data accumulated during a connection gap. Avoid QoS 2 on high-latency cellular links because the two-step handshake adds noticeable delay at each message delivery.

What MQTT broker should I use for a production IoT system?

For a pilot under 1,000 devices: Mosquitto on a dedicated VM is sufficient and free. For production under 10,000 devices: a managed broker like HiveMQ Cloud, AWS IoT Core, or EMQX removes the operational burden. For over 10,000 devices or enterprise SLA requirements: dedicated broker infrastructure with clustering is necessary. The choice between hosted and managed depends on whether your team has the operational experience to run broker infrastructure, not on technical capability. AWS IoT Core is the lowest-friction option for teams already on AWS.

How do I handle MQTT message loss if the device goes offline?

Configure the MQTT broker for persistent sessions with QoS 1 or QoS 2. A persistent session tells the broker to queue messages for an offline device and deliver them when it reconnects. Set a session expiry interval that matches your acceptable data gap. If 24 hours of offline time is acceptable, set session expiry to 24 hours. On the device side, implement a local ring buffer that stores readings during disconnection. When the connection re-establishes, flush the buffer to the broker before resuming live data. Without a local buffer, data collected during the outage is lost even with persistent sessions, because MQTT persistent sessions only queue messages sent to the device by the backend, not messages the device was trying to send.

Is HTTP or MQTT faster for IoT data delivery?

MQTT delivers individual messages faster because it uses an established connection rather than opening a new one for each message. The difference is most visible at high frequency. At 10+ messages per second, HTTP connection overhead dominates total latency. For single messages sent infrequently, the latency difference is small. The more meaningful comparison is throughput under load: MQTT can sustain thousands of messages per second through a broker with sub-millisecond delivery. HTTP at the same throughput requires connection pooling and significantly more server resources.

When should I switch from HTTP to MQTT if I already built on HTTP?

Switch when you see any of these: battery life falling short of target, backend struggling with reconnection storms, product roadmap requiring device-side command delivery, or polling overhead becoming visible in infrastructure costs. The migration path is: deploy an MQTT broker alongside the existing HTTP backend, update firmware to publish over MQTT while retaining HTTP as fallback, migrate data ingestion to subscribe from the broker, then deprecate HTTP. The firmware change is the critical path. Plan for a staged OTA rollout across the fleet.

Conclusion

The answer to whether you should use MQTT or HTTP for your IoT device is not about which protocol is better. It is about which one fits how your device actually behaves in the field - its message frequency, its power budget, its network environment, and whether the backend needs to reach back to it.

HTTP is the right starting point for simple, infrequent, mains-powered reporting where the team has no MQTT experience and the timeline is tight. MQTT is the right architecture for anything battery-powered, high-frequency, bidirectional, or deployed into environments where network reliability cannot be assumed.

Switching after the backend is built is possible. It costs 6 to 10 weeks. Deciding before costs an afternoon.

If you are scoping an IoT product and want a firmware and backend team that has built both MQTT and HTTP architectures in production across industrial, healthcare, and consumer devices , CoreFragment has shipped connected products on both sides of this decision. Share your device profile, your data rate, and your backend requirements and you will get a direct protocol recommendation before a single line of server code is written.