MQTT vs HTTP for IoT: when to use each protocol

One of the first technical decisions in an IoT project is choosing the communication protocol. MQTT and HTTP are the two main candidates, but they have completely different philosophies. Choosing wrong can mean batteries that drain in weeks instead of years, data lost without anyone knowing, or architectures that don’t scale.

This guide helps you make the right decision based on objective technical criteria and real experience implementing both protocols in production.

MQTT: designed for IoT

MQTT (Message Queuing Telemetry Transport) was created in 1999 by IBM for monitoring oil pipelines via satellite. The original context says it all: limited bandwidth, high latency, unstable connections and very resource-constrained devices.

Key MQTT characteristics

Pub/Sub model: Devices publish messages to topics. Consumers subscribe to topics they’re interested in. There’s no direct connection between producer and consumer: the broker manages all distribution.

Minimum overhead: MQTT’s fixed header is just 2 bytes. A typical message with topic and payload is 10-50 bytes. Compare with the 300-800 bytes of an equivalent HTTP request.

Three QoS levels:

• QoS 0: Fire and forget (maximum efficiency, no guarantee)
• QoS 1: At least once (delivery guarantee, possible duplicates)
• QoS 2: Exactly once (maximum reliability, more overhead)

Persistent sessions: The broker stores messages for disconnected devices and delivers them upon reconnection.

Last Will and Testament (LWT): The broker publishes a predefined message if it detects a device has disconnected unexpectedly. Perfect for fault detection.

Efficient keep-alive: Periodic pings of a few bytes to keep the connection alive through NATs and firewalls.

When to use MQTT

• Battery-powered devices (every byte counts)
• Mobile/LoRaWAN/NB-IoT connectivity with variable latency
• Data that must arrive in real time (monitoring, alerts)
• Bidirectional communication (sending commands to device)
• Thousands of devices publishing to the same broker
• Devices that connect and disconnect frequently

HTTP: the universal protocol

HTTP is the web protocol. Every developer knows it, every tool supports it, every firewall lets it through. But it wasn’t designed for IoT.

Key HTTP characteristics for IoT

Request/Response model: The client always initiates communication. The server cannot proactively send data to the device (without WebSocket or SSE).

Significant overhead: Typical HTTP headers occupy 300-800 bytes. For a sensor sending 10 bytes of data, that’s 98% overhead.

Stateless: Each request is independent. No concept of persistent session or pending messages. If the server wants to send something to the device, it must wait for the device to poll.

Mature ecosystem: Well-documented REST APIs, OAuth2 authentication, debugging tools, SDKs in every language, trivial integration with any system.

Standard TLS: HTTPS works everywhere. Free Let’s Encrypt certificates. No special configuration required.

When to use HTTP

• Devices with constant power and WiFi/Ethernet
• Infrequent data transmission (once daily, hourly)
• Large payloads (images, logs, configuration files)
• Integration with existing REST APIs
• OTA firmware updates
• Gateways and edge devices with abundant resources

Detailed technical comparison

Network overhead

For a sensor sending a reading every 5 minutes for a month:

• MQTT: ~20 bytes * 8,640 messages = 173 KB
• HTTP: ~350 bytes * 8,640 requests = 3 MB

That’s 17x more data with HTTP. On networks with per-MB costs (NB-IoT, LTE-M), the difference is real on the bill.

Battery consumption

Radio consumption is the main battery drain in IoT devices. Fewer bytes = less active radio time = more battery life.

These are approximate values for a typical device with 3,600 mAh battery and LoRaWAN/NB-IoT radio.

Latency

MQTT clearly wins in bidirectional scenarios. If you need to send a command to a device and receive confirmation in under a second, HTTP with polling isn’t viable.

Reliability

Scalability

Hybrid architecture: the best of both worlds

In practice, most industrial IoT projects use both protocols:

Devices → MQTT → Broker → Processing
                                ↓
                         REST API (HTTP)
                                ↓
              Dashboards / Apps / Integrations

• MQTT for device-cloud communication: efficient, bidirectional, disconnect-tolerant
• HTTP/REST for the backend API: dashboards, mobile apps, third-party system integrations

This is exactly the architecture we implement at Spherag: devices publish via MQTT to AWS IoT Core, processing happens in Lambda/Kinesis, and data is exposed via REST API + WebSocket for the dashboard.

Cases where MQTT is clearly better

1. High-frequency telemetry

An industrial sensor sending vibration at 100 Hz (100 messages/second). With HTTP, each message would need a complete round-trip. With MQTT, messages flow through the persistent connection with minimum overhead.

2. Battery-powered sensor networks

LoRaWAN or NB-IoT devices that must operate for years on a battery. Every extra byte reduces lifespan. MQTT with QoS 0 minimises consumption.

3. Remote device commands

You need to open a valve, change a sensor configuration or update a parameter. With MQTT, the device is subscribed to a command topic and receives the instruction immediately. With HTTP, you’d have to wait for the device to poll.

4. Disconnect detection

In critical infrastructure monitoring, you need to know within seconds if a device has disconnected. MQTT’s LWT does this automatically. With HTTP, you’d only find out when the next poll doesn’t arrive (which could be minutes or hours later).

Cases where HTTP is better or equal

1. Devices with stable WiFi connectivity

A gateway with WiFi/Ethernet and constant power can use HTTP without significant penalty. If it only sends data every minute, the extra overhead is irrelevant.

2. Large file transmission

Firmware updates, compressed logs, camera images. HTTP with chunked transfer or multipart is more suitable than MQTT for KB or MB payloads.

3. Integration with legacy systems

If your target system only accepts HTTP/REST, a gateway that translates MQTT to HTTP is the most pragmatic solution.

4. Rapid prototyping

For a quick MVP with few devices, HTTP may be simpler to implement if the team already has REST API experience.

MQTT over WebSocket: the perfect bridge

A special case: MQTT over WebSocket allows web browsers to subscribe directly to MQTT topics. This is ideal for real-time dashboards that need to receive data from the broker without an intermediate backend.

Device → MQTT → Broker
                  ↓
Browser → MQTT over WebSocket → Broker

AWS IoT Core supports MQTT over WebSocket natively, allowing a React dashboard to subscribe to the same topics as the backend without additional server code.

Practical recommendations

1. If you have battery-powered devices: MQTT, no question
2. If you need bidirectionality: MQTT
3. If sending data every few seconds: MQTT
4. If only sending data 1x daily with WiFi: HTTP is fine
5. If sending large files: HTTP for files, MQTT for signalling
6. If you don’t know what to choose: MQTT. It’s more versatile and you won’t need to migrate when requirements grow

Implementation with Soamee

At Soamee we implement MQTT and AWS IoT architectures for industrial IoT projects. If you need help choosing and designing the communication architecture for your IoT project, book a free consultation.