A client came to us last year with a fleet of soil moisture sensors that were burning through their battery budget in weeks instead of the eighteen months the hardware datasheet promised. The sensors were fine. The radio was fine. The problem was that every reading opened a fresh HTTPS connection, negotiated TLS, sent 14 bytes of useful payload wrapped in roughly a kilobyte of headers and handshake, then tore everything down. Thirty times an hour. Forever.
Protocol choice is one of those decisions that looks like a detail on the architecture diagram and turns into the thing that determines whether your product ships. So let's be concrete about what MQTT, CoAP and HTTP actually do, where each one wins, and — because this matters more than most comparison articles admit — when the boring choice is the right one.
The one-paragraph version
MQTT is a publish/subscribe protocol over a persistent TCP connection, designed for many devices talking to a central broker. CoAP is a request/response protocol over UDP that looks and feels like HTTP but with binary headers and a 4-byte fixed overhead, designed for constrained devices and constrained networks. HTTP is what everything already speaks, with the heaviest per-message cost and the deepest ecosystem on earth. If you need push from cloud to device at scale, you probably want MQTT. If you have battery-powered devices on a mesh or NB-IoT link, look hard at CoAP. If your devices have mains power, decent bandwidth, and you value shipping over elegance, HTTP is not the wrong answer.
Bandwidth and message overhead
This is where the differences are least arguable, because you can count bytes.
- MQTT: a 2-byte fixed header plus a variable header. A PUBLISH to a short topic costs a handful of bytes on top of your payload. The connection setup (CONNECT/CONNACK, plus TLS if you're using it) is paid once and amortised across every message that follows — which is exactly why it suits devices that report frequently.
- CoAP: a 4-byte fixed header plus compact binary options. No connection setup at all, because UDP. A single GET or a single POST with a small payload can fit comfortably inside one packet, which matters a great deal on 6LoWPAN where the link MTU is around 127 bytes.
- HTTP/1.1: verbose text headers. A realistic request with a Host, User-Agent, Content-Type, Content-Length and an Authorization bearer token runs several hundred bytes before your payload starts. Add TLS handshake bytes and round trips on every new connection.
The nuance people miss: HTTP/2 and HTTP/3 change this picture. HPACK and QPACK header compression cut repeated headers dramatically, and HTTP/3 over QUIC gives you connection migration and fewer handshake round trips. If your device runs a real OS and a modern TLS stack, HTTP is no longer the bloated option it was in 2015. The gap narrows to something you might reasonably ignore.
But on a Cortex-M0 with 32 KB of RAM and a LoRaWAN or NB-IoT modem, that modern stack doesn't fit, and you're back to comparing raw byte counts.
Reliability, and what "reliable" actually means
All three can be made reliable. They put the work in different places.
MQTT
MQTT gives you three quality-of-service levels: QoS 0 (fire and forget), QoS 1 (at least once, with possible duplicates), QoS 2 (exactly once, via a four-part handshake). It also gives you two features that are genuinely hard to replicate elsewhere: retained messages, so a subscriber gets the last known value the instant it connects, and Last Will and Testament, so the broker announces a device's ungraceful disconnect on its behalf. For monitoring and alerting systems, LWT alone can justify the protocol choice.
In practice we default to QoS 1 with idempotent message handling on the server. QoS 2 costs round trips and broker state, and most teams that think they need exactly-once delivery actually need idempotent processing, which is cheaper and more robust.
CoAP
CoAP runs on UDP but is not unreliable. Confirmable messages get ACKs with exponential backoff retransmission; non-confirmable messages don't. You choose per message. That granularity is useful: send routine telemetry as non-confirmable, send configuration changes as confirmable. Block-wise transfer lets you move payloads larger than a datagram, and the Observe extension gives you a subscription-like push model without a persistent connection.
HTTP
HTTP inherits TCP reliability and gives you status codes, retries with Retry-After, idempotency via PUT, and every caching and load-balancing tool ever written. The weakness isn't reliability — it's that cloud-to-device push requires polling, long polling, WebSockets or server-sent events, each of which adds moving parts.
Power consumption
For battery devices, radio-on time is your budget. Everything else is noise.
MQTT keeps a TCP connection alive, which means periodic PINGREQ traffic. On Wi-Fi that's negligible. On a cellular link where the modem has to leave a low-power state to send a keepalive, it's a real cost, and aggressive keepalive intervals will wreck your battery projections. NB-IoT and LTE-M give you eDRX and PSM to work around this, but you have to configure keepalives to match the sleep schedule rather than fight it.
CoAP has no keepalive concept. Wake, send a datagram, optionally wait for an ACK, sleep. That's it. For a device reporting once an hour and sleeping otherwise, this is close to the theoretical minimum. If you need security, DTLS with connection ID or the newer OSCORE approach keeps the handshake cost from eating the savings.
HTTP is the worst case for infrequent reporting because you pay full connection and TLS setup for every burst. It's perfectly fine for mains-powered gateways, cameras, kiosks, and anything that talks continuously.
Ecosystem, tooling and the cost of your team's time
This is the factor engineering teams systematically underweight, and it's usually the one that decides project timelines.
- HTTP: every language, every framework, every developer. API gateways, WAFs, CDNs, observability, auth providers, Postman, curl. Zero onboarding cost. Debuggable by anyone on your team at 2am.
- MQTT: excellent and mature. Mosquitto, EMQX, HiveMQ, NanoMQ; native support in AWS IoT Core, Azure IoT Hub and Google's ecosystem; solid client libraries for embedded C, Python, Go, Rust, JS. MQTT over WebSockets means browsers can subscribe directly. Good tooling with MQTT Explorer and similar. Broker operations — clustering, persistence, shared subscriptions — is a real skill you need on the team or in your managed service.
- CoAP: capable but thinner. libcoap, Californium, aiocoap, Zephyr and Contiki-NG integration are all solid. Managed cloud support is weaker; you'll typically run a proxy that translates CoAP to HTTP or MQTT at the edge. Fewer engineers have touched it, so budget learning time.
There is a hidden cost in choosing the unfamiliar protocol: every debugging session takes longer, every new hire takes longer to become productive, and every integration with a third party needs a bridge. Sometimes that cost is worth paying. Often it isn't.
How we actually decide
When we scope an IoT build, the protocol question falls out of four answers.
- Is the device battery powered, and what's the required life? Under a year on mains-adjacent power: anything works. Multi-year on a coin cell or primary battery: CoAP, or MQTT with carefully tuned keepalives and a sleep-aware broker session.
- Do you need cloud-to-device push, and how fast? Sub-second command delivery to thousands of devices is MQTT's home turf. Config that can arrive within the next reporting interval doesn't need push at all — the device can pull it.
- What's the link? Wi-Fi or Ethernet: HTTP or MQTT. Cellular IoT (NB-IoT, LTE-M): CoAP or MQTT-SN, and check what your carrier and module actually support. 6LoWPAN, Thread, Zigbee mesh: CoAP, with a gateway translating outward.
- What does the device firmware stack allow? If you're on Zephyr, FreeRTOS or an ESP32, all three are available. If you're on a vendor SDK with a fixed TCP/IP stack and 20 KB of headroom, your options narrow fast.
And one more thing we say to almost every client: you don't have to pick one. Most production systems we've designed use two. Devices speak MQTT or CoAP to a broker or edge gateway; that gateway exposes HTTP APIs to dashboards, mobile apps, ERPs and analytics pipelines. The protocol boundary sits at the edge where it belongs, and each side uses what it's good at. If you're integrating device data with business systems — say pushing device-triggered service alerts into a sales pipeline — that HTTP layer is where it happens, and it's the same pattern we use when wiring Orbis Lead CRM into external data sources.
What changes in 2026
Nothing revolutionary, which is good news for anyone making a decision now.
- MQTT 5 features — shared subscriptions, message expiry, topic aliases, reason codes, request/response correlation — are now well supported across brokers and worth adopting over 3.1.1 for new work.
- Matter has pulled Thread and IPv6-based device networking into the mainstream, which quietly increases the number of projects where CoAP is the natural fit at the device layer.
- HTTP/3 and QUIC keep eroding the "HTTP is too heavy" argument for anything with real compute. MQTT over QUIC is available in some brokers and worth watching, though we wouldn't build a production fleet on it without careful testing.
- On-device inference is pushing more filtering to the edge, which means fewer, richer messages instead of a firehose of raw readings. That shifts the cost calculus away from per-message overhead and toward payload structure. If that's your direction, our AI and ML engineering work covers the model-at-the-edge side of it.
A short opinion, since you asked
If you're building a connected product and you genuinely don't know which to choose, start with MQTT. It handles the widest range of IoT shapes, the tooling is good, the hosted options are mature, and it degrades gracefully as your fleet grows. Move to CoAP when battery measurements or a constrained mesh force your hand. Stay on plain HTTP when your devices are powered, your message rate is modest, and your team's velocity matters more than saving a few hundred bytes per request — that's a legitimate engineering trade-off, not laziness.
What you should avoid is choosing based on a benchmark chart without modelling your own traffic pattern, duty cycle and security requirements. Spend a week on a spike with real hardware on the real network. The answer usually becomes obvious.
If you're weighing this decision for a product that has to work in the field for years, we're happy to talk through the specifics — duty cycles, carrier constraints, firmware headroom, the whole picture. Have a look at some of the systems we've built, or get in touch and tell us what you're putting on the network.
