The IoT platform vs MQTT broker question confuses many teams because the two overlap and vendors use the terms loosely. This article separates the layers clearly, explains what a full IoT platform adds on top of a broker, and gives you a practical way to decide whether you need a platform or whether a lean managed broker plus a few open tools covers your project.
Two Different Layers
An MQTT broker is a message router. Clients connect, publish messages to topics and subscribe to topics; the broker delivers each message to every matching subscriber with the requested QoS. It handles sessions, retained messages, will messages and, with MQTT 5, features such as shared subscriptions and message expiry. If you need a refresher, read what an MQTT broker does.
An IoT platform is a bundle of services built around a messaging core. Depending on the product, it adds some or all of:
- Device registry, provisioning and identity management.
- Device state services such as shadows or twins.
- Over-the-air firmware update orchestration.
- Rules engines that filter, transform and route data.
- Time-series storage and historical queries.
- Dashboards, alarms and notifications.
- User management, multi-tenancy for your own customers, and application APIs.
Many platforms include an MQTT endpoint, sometimes a full broker and sometimes a device-to-cloud gateway with fixed topics. The platform's value is the integration of all those pieces.
IoT Platform vs MQTT Broker Compared
| Capability | MQTT broker alone | Full IoT platform | Lean broker plus open tools |
|---|---|---|---|
| Real-time pub/sub | Yes | Usually, sometimes device-to-cloud only | Yes |
| Device identity | Credentials per client | Registry with lifecycle | Credentials plus your own inventory |
| Device state | Retained messages | Shadow or twin service | Retained state topics |
| Data processing | No | Built-in rules | Node-RED, small services |
| Storage and history | No | Built in | InfluxDB, TimescaleDB, PostgreSQL |
| Dashboards | Broker console only | Built in | Grafana, Node-RED Dashboard |
| Alerts | Depends on broker | Built in | Broker alerts or Grafana alerting |
| Firmware updates | No | Often built in | Separate OTA tooling |
| Portability | High | Often lower | High |
| Effort to start | Low | Low to medium | Medium |
The middle column is convenient and opinionated. The right column takes a little more assembly but leaves every part replaceable.
When a Full IoT Platform Is the Right Choice
A platform earns its cost and constraints when:
- You need large-scale device lifecycle management such as bulk provisioning, certificate rotation and staged OTA updates across many device types.
- You lack the people to integrate components and want one vendor responsible for the whole stack.
- Your back end already lives in that platform's cloud and you want data to land there with minimal glue.
- You are building a multi-customer product and the platform's tenant, user and API model matches yours.
In these cases, choose the platform deliberately and read MQTT vendor lock-in to keep device firmware as portable as practical.
When a Lean Broker Is Enough
A managed broker plus a few open tools is often the better choice when:
- Your core need is live data movement between machines, gateways, apps and dashboards.
- You already use tools like Node-RED, Grafana, Telegraf or a time-series database.
- You are building a Unified Namespace and want to own the topic hierarchy completely.
- You value portability across clouds and on-premises systems.
- Your fleet is modest and device management can live in a simple inventory.
ConnectMQ is designed for this pattern. It is a fully managed MQTT service with MQTT 3.1.1 and 5.0, TLS and Secure WebSocket, and a portal that covers several "platform-like" basics without becoming a platform: an in-browser MQTT client, live topic explorer, dashboard, devices view by ISA-95 levels, threshold alert rules with an alerts log, Sparkplug B decoding and republishing into ISA-95 topics. It deliberately does not include a rule engine, webhooks or database bridges; those jobs go to external tools.
A Lean Reference Architecture
A common, fully open stack around a managed broker looks like this:
Devices / PLC gateways --MQTT/TLS--> Managed MQTT broker (ConnectMQ)
|
+-------------------------------+-----------------------------+
| | |
Telegraf (mqtt_consumer) Node-RED flows Browser apps (WSS 8084)
| (logic, alerts, APIs)
InfluxDB (time series)
|
Grafana (dashboards, alerting)
Each component connects to the broker as an ordinary MQTT client. You can replace any one of them without touching devices.
Example: Storing Telemetry With Telegraf
Telegraf's MQTT consumer input can subscribe to your broker and write to InfluxDB with configuration only:
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["acme/plant1/+/+/telemetry"]
qos = 1
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
data_format = "json"
topic_tag = "topic"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "acme"
bucket = "telemetry"
Start it and check that points arrive:
export INFLUX_TOKEN=your-influx-token
telegraf --config telegraf.conf --test # one-shot parse check
telegraf --config telegraf.conf # run continuously
With JSON payloads like {"temp": 72.4, "rpm": 1450}, numeric fields become InfluxDB fields and the topic becomes a tag you can filter on in Grafana. Remember that each simultaneous connection needs its own credentials and client ID; on ConnectMQ, client IDs are bound to issued credentials.
Hidden Costs on Both Sides
Neither path is free of trade-offs, and it helps to name them before deciding.
With a full platform, the hidden costs are usually conceptual and contractual. Your team learns the platform's model of devices, rules and state, and that knowledge does not transfer elsewhere. Pricing often grows with several dimensions at once, such as connections, messages, rule executions and storage, which makes forecasting harder. And features you do not use still shape how you design the ones you do.
With a lean broker plus tools, the hidden costs are operational. Someone must run Node-RED, the time-series database and Grafana, keep them updated and back them up. Integration decisions, such as topic naming and payload formats, are yours to document and enforce. For a small team this is manageable; for a large organisation without a platform team it can become scattered.
The practical test is to sketch the next two years: how many devices, which data destinations, and who maintains each piece. The option whose maintenance burden matches your team is usually the right one.
Decision Checklist
Answer each question with yes or no:
- Do you need OTA firmware orchestration across a large fleet from one console?
- Do you need a device registry with lifecycle states beyond a list of credentials?
- Must data land automatically in one specific cloud's services?
- Do you lack anyone comfortable running Node-RED, Grafana or a small service?
- Do you need a ready-made multi-tenant application layer for your own customers?
Mostly yes: evaluate full IoT platforms. Mostly no: start with a lean managed broker and add tools as needs appear. Many teams also combine both, using a broker as the neutral real-time backbone and a platform for one specific job such as OTA updates.
For deeper comparisons, see AWS IoT Core alternative and Azure IoT Hub alternative, which look at two well-known platforms through this lens.
Start With a Lean Managed Broker
You can validate the lean approach in an afternoon. Create a free Serverless broker with no credit card, connect a device, and point Telegraf or Node-RED at it. The cloud MQTT broker guide explains deployment options as your project grows, and connectmq.com has the full plan overview, from Serverless to Dedicated, BYOC and Self Managed Enterprise.
Frequently Asked Questions
Is an MQTT broker an IoT platform?
No. A broker routes messages between clients. An IoT platform bundles a messaging layer with device management, storage, rules and dashboards.
Can I build an IoT solution with only an MQTT broker?
Yes, with a few external tools. A broker plus Node-RED, a time-series database and Grafana covers many monitoring and control projects.
Does ConnectMQ include a rule engine or database integrations?
No. Integrations run as external MQTT clients such as Node-RED, Telegraf or your own services, which keeps them portable.
Can I use an IoT platform and a separate MQTT broker together?
Yes. Many teams use a neutral broker as the real-time backbone and a platform for specific jobs such as firmware updates or device provisioning.
