Picking an IoT MQTT broker is one of the few infrastructure decisions that touches every device you will ever ship, so it pays to get it right before the first firmware release. This guide gives you a 12-point checklist, a table of questions to ask any vendor, and a quick hands-on test you can run in five minutes. Along the way we show how ConnectMQ answers each point — using only features it actually has.
If you are still deciding between running your own broker and using a service, read What Is a Managed MQTT Broker? first.
Why the Choice of IoT MQTT Broker Matters
The broker sits in the middle of every message: devices publish to it, applications subscribe through it. Once thousands of devices have a hostname, port, certificate chain and topic structure burned into their firmware, changing brokers becomes an expensive migration. The broker also defines your security boundary, your scaling ceiling and a big part of your monthly operating cost.
A good selection process therefore looks beyond "does it speak MQTT?" and checks protocol depth, security, isolation, operations and the path from prototype to production.
The 12-Point IoT MQTT Broker Checklist
1. Protocol Support: MQTT 3.1.1 and MQTT 5.0
Most existing devices and libraries speak MQTT 3.1.1, while new projects benefit from MQTT 5.0 features: reason codes, session and message expiry, topic aliases, shared subscriptions and request/response. A broker should support both side by side so old and new devices can coexist. Check which MQTT 5 features are actually implemented, not just whether the CONNECT packet is accepted. The full feature list is in the OASIS MQTT 5.0 specification, and our MQTT 5 features guide explains them in practice.
ConnectMQ: supports MQTT 3.1.1 and MQTT 5.0, including shared subscriptions, retained messages, session expiry, topic alias, message expiry interval, response topic and reason codes. CONNACK announces the broker's limits (Maximum QoS, Retain Available, Wildcard and Shared Subscription Available, Receive Maximum).
2. Transport: TCP, TLS and WebSocket
Devices on constrained networks may use plain TCP during development, but production traffic should be encrypted. Browsers and dashboards need MQTT over WebSocket, ideally Secure WebSocket (WSS) so they work from HTTPS pages.
ConnectMQ: TCP on 1883, TLS on 8883, WebSocket on 8083 and WSS on 8084 (path /mqtt), with a Let's Encrypt certificate that standard CA stores already trust.
3. Authentication
Ask how devices prove their identity and how credentials are issued and rotated. At a minimum you want per-broker credentials and protection against clients impersonating each other through the client ID.
ConnectMQ: username and password are issued per broker in the portal, and client IDs are restricted to the issued client ID and its _suffix variants (for example YOUR_CLIENT_ID_sensor1). See MQTT security best practices for the full picture.
4. Multi-Tenancy and Isolation
On a shared service, your topics must be invisible to every other customer. If you build a product for your own customers, you need the same guarantee one level down.
ConnectMQ: each tenant's topics are isolated from other tenants and from the public test area. If you need isolation at the infrastructure level as well, the Dedicated plan gives you a broker cluster of your own.
5. Scalability and Connection Limits
Look at concurrent connection limits per plan, message size limits and how you grow from one tier to the next without changing device code.
ConnectMQ: Serverless (Free) allows up to 25 concurrent connections and 256 KB messages; Serverless (Paid) up to 1,000 connections and 1 MB messages; Dedicated, BYOC and Self Managed Enterprise cover larger and isolated deployments.
6. QoS and Sessions
QoS 1 and 2 give you delivery guarantees; persistent sessions let devices that reconnect pick up queued messages. Confirm which QoS levels each plan supports and how long sessions are kept. Background: MQTT QoS Levels Explained.
ConnectMQ: QoS up to 1 on Serverless (Free), QoS 2 on Serverless (Paid); session expiry is capped per plan.
7. Retained and Offline Messages
Retained messages give every new subscriber the last known value immediately — essential for device status and configuration. Last Will messages tell the rest of the system when a device drops off.
ConnectMQ: retained messages are supported on every plan, Last Will messages are delivered as the specification requires, and $SYS/broker/connection/{clientId}/state exposes a client's connection state.
8. Industrial Standards: Sparkplug B and ISA-95
Factories increasingly organise data in a Unified Namespace following ISA-95 levels (enterprise, site, area, line, cell) and use Sparkplug B for typed, stateful payloads. A broker that understands these conventions saves integration work.
ConnectMQ: detects ISA-95 / Unified Namespace topic structures, detects and decodes Sparkplug B (Protobuf and JSON) and can republish Sparkplug B into an ISA-95 structure — for example spBv1.0/factory1/DDATA/line1/cnc1 becomes connectmq/factory1/production/line1/cnc1/telemetry. More in Sparkplug B and the Unified Namespace.
9. Observability
When a device misbehaves at 3 a.m., you need to see what it published and why it was rejected. Look for a live topic view, connection state and meaningful error codes.
ConnectMQ: the portal includes a dashboard, an in-browser MQTT client, a live topic explorer, a devices view organised by ISA-95 levels, threshold alert rules and an alerts log. MQTT 5 reason codes such as 0x97 (Quota exceeded) and 0x89 (Server busy) explain rejections, and the ConnectMQ VS Code extension shows CONNACK, SUBACK and PUBACK reason codes during development.
10. Deployment Models
Some teams want zero operations; others must keep data in their own cloud account or on-premises.
ConnectMQ: Serverless (shared cluster), Dedicated (isolated cluster), BYOC (brokers in your own cloud account, managed by ConnectMQ) and Self Managed Enterprise (licensed broker on your own infrastructure).
11. Quotas and Protection
A single buggy device stuck in a reconnect loop can hurt everyone on the broker. Ask how the broker defends itself and your tenant.
ConnectMQ: per-plan quotas, connection-flood protection with temporary bans, IP blocking after repeated bad-credential attempts and adaptive overload protection.
12. Cost and Operations
Compare the total cost: compute, storage, patching, certificate renewal, monitoring, on-call time and upgrades. A free tier that lets you prototype without a credit card lowers the risk of evaluating.
ConnectMQ: a fully managed service with a free Serverless plan (no credit card) and paid tiers when you need production limits. Check the current plan details on connectmq.com.
What to Ask Your IoT MQTT Broker Vendor
Use this table as an evaluation sheet. Copy it into your own document and fill in one column per candidate.
| Criterion | Question to ask | ConnectMQ answer |
|---|---|---|
| Protocol | Which MQTT versions and which MQTT 5 features are implemented? | MQTT 3.1.1 and 5.0; shared subscriptions, topic alias, expiry, response topic, reason codes |
| Transport | Which ports for TCP, TLS, WS and WSS? Which certificate? | 1883, 8883, 8083, 8084; Let's Encrypt |
| Authentication | How are credentials issued? Can a device spoof another client ID? | Per-broker username/password; client ID restricted to issued ID and _suffix variants |
| Isolation | Can other customers see my topics? | No, tenant topics are isolated |
| Scale | What are connection and message size limits per plan? | 25 / 256 KB (Free), 1,000 / 1 MB (Paid), Dedicated for more |
| QoS | Which QoS levels per plan? Session expiry? | QoS 1 (Free), QoS 2 (Paid); session expiry capped per plan |
| State | Retained messages, Last Will, connection state? | Yes; $SYS/broker/connection/{clientId}/state |
| Industrial | Sparkplug B and ISA-95 support? | Detects and decodes Sparkplug B, republishes to ISA-95 topics |
| Observability | Can I see live topics, devices and alerts? | Portal dashboard, topic explorer, devices view, alert rules |
| Deployment | Shared, dedicated, my cloud, on-prem? | Serverless, Dedicated, BYOC, Self Managed Enterprise |
| Protection | How are floods and brute-force attempts handled? | Quotas, flood bans, IP blocking, overload protection |
| Trial | Can I test without a credit card? | Yes, Serverless (Free) and the public test broker |
Also ask each vendor what is not included. For example, ConnectMQ focuses on the broker itself: it does not offer a server-side rule engine, webhooks or built-in data bridges to Kafka or databases, so plan to consume data with your own subscriber service if you need them.
Quick Test Against broker.connectmq.com
Datasheets only go so far. Before shortlisting any IoT MQTT broker, connect a real client. The ConnectMQ public test broker needs no account — just a non-empty client ID and a unique topic prefix (everything in the public area is readable by others, so use test data only). Details are in our free public MQTT broker guide.
export ID=eval-$(openssl rand -hex 3)
# Terminal 1: subscribe with MQTT 5
mosquitto_sub -h broker.connectmq.com -p 1883 -i $ID-sub -t "connectmq/demo/$ID/#" -v -V mqttv5
# Terminal 2: publish a retained status and a telemetry reading over TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/status" -m "online" -r -q 1
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/telemetry" -m '{"temp": 23.1}'
# Clean up the retained message
mosquitto_pub -h broker.connectmq.com -p 1883 -i $ID-pub -t "connectmq/demo/$ID/status" -n -r
On Windows or macOS, replace --capath /etc/ssl/certs with --cafile pointing to a PEM CA bundle. During the test, check the criteria you can observe directly:
- Latency: messages should appear in Terminal 1 almost instantly.
- Retained messages: stop and restart the subscriber — the
onlinestatus arrives straight away. - Last Will: add
--will-topic "connectmq/demo/$ID/status" --will-payload offlineto a client and kill it; the subscriber receivesoffline. - Limits: the public area allows 64 KB per message and 10 messages per second per client; exceeding them returns MQTT 5 reason codes rather than silent drops.
For a production evaluation, repeat the test with a private broker and the credentials from the portal:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t "#" -v
Get Started with ConnectMQ
The best way to evaluate an IoT MQTT broker is to connect your own devices to it. Sign up at app.connectmq.com — the Serverless (Free) plan needs no credit card. Create a broker, copy the generated username, password and client ID, and watch your first messages arrive in the live topic explorer.
Frequently Asked Questions
What is the most important criterion when choosing an IoT MQTT broker?
Security and isolation come first: encrypted transport, per-device authentication and guaranteed separation from other tenants. After that, check MQTT 5 support and limits that match your fleet size.
Do I need MQTT 5.0 for an IoT project?
Not strictly, since MQTT 3.1.1 still works well, but MQTT 5 adds reason codes, expiry intervals, shared subscriptions and request/response that make larger systems easier to run. Choose a broker that supports both versions.
Does ConnectMQ support Sparkplug B?
Yes. ConnectMQ detects and decodes Sparkplug B payloads (Protobuf and JSON) and can republish them into an ISA-95 Unified Namespace topic structure.
Can I test ConnectMQ without creating an account?
Yes. Connect to broker.connectmq.com without credentials, using a non-empty client ID and a unique topic prefix. Remember that the public area is readable by everyone.
Can I run ConnectMQ in my own cloud or data center?
Yes. Besides the Serverless and Dedicated plans, ConnectMQ offers BYOC (brokers in your own cloud account, managed by ConnectMQ) and Self Managed Enterprise for your own infrastructure.
