When a physical product starts talking to a server, one of the first architecture questions is whether to use MQTT or HTTP. Both work, both are supported by every major cloud platform, and both are mature and well understood — so the decision is rarely a purely technical one. It follows from the character of the product: how often it reports, how fast it must react to a command from the cloud, and how much energy it can afford to spend. The short version: HTTP if the device is mains-powered and reports occasionally; MQTT if it runs on a battery, needs to receive commands in real time, or ships in large numbers.

Two Fundamentally Different Models

HTTP is request/response. The device initiates a call to the server, receives an answer, and the connection closes. It is the same model that drives the web, which is exactly why it is familiar to every developer, trivially debuggable with standard tools, and easy to test with nothing but a command-line client.

MQTT is publish/subscribe. The device opens one persistent connection to a broker, publishes messages to topics, and subscribes to other topics to receive them. The connection stays open, and the messages themselves are tiny — tens of bytes of overhead where an HTTP request carries hundreds. That difference sounds small on paper, and it propagates into nearly every other decision in the system.

When HTTP Is the Right Choice

If your product reports every few minutes or hours, is plugged into a wall, and never needs to receive an instruction the instant a user taps a button, HTTP will be simpler and cheaper to develop. Your team already knows it. Every backend framework speaks it natively. Logs are readable. There is no broker to operate.

HTTP is also the better choice for anything large: images, log bundles, and firmware images. It has built-in support for chunked and resumable transfers, and content delivery networks handle it for free. Many products end up with a deliberately mixed architecture — light telemetry over one channel, heavy transfers over another — which is a perfectly respectable design rather than a compromise. If you have not chosen a backend yet, our comparison of AWS IoT vs Azure IoT covers what each platform gives you out of the box.

When MQTT Wins

MQTT earns its keep when there are many devices, genuine two-way communication, or an energy budget. The classic cases:

  • Remote control. The user presses a button in the app and the product must respond immediately. With HTTP the device has to poll the server repeatedly, which burns power and adds latency you cannot design away.
  • Battery-powered products. Publishing a short message on an existing connection costs far less energy than negotiating a fresh encrypted session for every report.
  • Large fleets. At thousands of units, the reduction in bytes and server load becomes a line item on the cloud bill, not a rounding error.
  • Weak cellular coverage. MQTT handles intermittent connectivity better, including delivery-guarantee levels and last-will messages that tell your backend a device dropped off.

The counterweight is operational. MQTT requires broker infrastructure, dedicated monitoring, and operational knowledge not every small team has. On a first product with a handful of prototypes in the field, that is a real cost, not a theoretical one.

Energy: Usually the Deciding Factor

For anything on a battery, the protocol decision is effectively a battery-life decision. Establishing a new encrypted session involves a multi-round-trip handshake that keeps the radio and the modem awake for a comparatively long time, and on cellular that wake-up dominates the energy cost of the entire transaction. If the device reports frequently, the difference between protocols translates directly into additional months of field life — or into a physically larger battery, which changes the enclosure and the cost. This has to be modeled during architecture, not measured after the first prototype, and it belongs alongside the microcontroller decision covered in how to choose a microcontroller.

Security and Key Management

Both protocols are encrypted in transit — MQTT over TLS, HTTP over TLS — so transport security is not a differentiator. The real work is identical either way and is routinely underestimated: every device needs a unique credential, that credential has to be provisioned during production test, it has to be revocable when a unit is stolen or compromised, and it has to survive a firmware update. Design a per-device identity from the start; shared credentials across a fleet are the single most common security defect in connected hardware.

The Operational Side

Whichever protocol carries the packets, both feed the same downstream systems: a dashboard, an alerting path, a data store, and an update mechanism. Your OTA firmware update pipeline in particular is protocol-agnostic in its logic even though the transport differs — MQTT typically signals that an update is available while HTTP delivers the image itself. Budget for the ongoing cost of that infrastructure; it is one of the expenses first-time hardware teams forget, as our breakdown of IoT product development cost shows.

How to Decide in Practice

Four questions settle it almost every time:

  • How often does the device report? Seconds favors MQTT; hours favors HTTP.
  • Does the cloud need to push a command the device must act on immediately? If yes, MQTT.
  • What powers it? Battery favors MQTT; mains is neutral.
  • How many units in the next few years? Tens favors HTTP's simplicity; thousands favors MQTT's efficiency.

If two or more answers point toward real-time or battery, choose MQTT. If the product is plugged in and reports rarely, HTTP will save development time you can spend on the hardware instead — and firmware time is expensive, as our article on firmware development cost makes clear.

One last point: the decision is not permanent. A well-structured firmware architecture isolates the transport layer behind an internal messaging interface, so swapping protocols later means rewriting one module rather than the product. Insist on that separation in code review even if you are confident in today's choice.

Design the Whole Chain, Not Just the Protocol

Projects House architects connected products end to end — hardware, firmware, cloud, and app — with production cost and development time treated as design constraints from the first diagram. Not sure which architecture fits your product? Describe it through our contact form and we will lay out the full picture before anyone writes a line of code. More in our software development knowledge center.