A dedicated MQTT broker gives one customer an isolated broker cluster instead of a slice of a shared one, so performance and capacity are reserved for your fleet alone. This guide explains what isolation buys you, the signals that you have outgrown a serverless tier, how to plan capacity before you switch, and a practical checklist for moving from ConnectMQ Serverless to Dedicated.
What a Dedicated MQTT Broker Is
On a serverless tier, many tenants share one cluster and are separated logically by credentials, topic namespaces and quotas. A dedicated deployment removes the sharing: the provider runs a broker cluster that serves only your organization. You still do not manage servers, operating systems or certificates, because it remains a hosted MQTT broker, but the compute, memory and network behind your endpoint are not shared with anyone else.
That distinction matters less than people expect for small fleets and much more than they expect for large or latency-sensitive ones. If you are still deciding between hosting models at a high level, the cloud MQTT broker pillar explains the full landscape.
What Isolation Buys You
Predictable Performance
On a shared cluster, quotas keep any single tenant from monopolizing resources, but your traffic still runs alongside everyone else's. With a dedicated MQTT broker, a spike from another company simply cannot affect you. Latency and throughput depend on your own workload, which makes behaviour easier to reason about and to test.
Capacity Headroom You Can Plan Around
Shared tiers have fixed quotas per plan. A dedicated cluster is sized for your expected load, so you plan headroom deliberately instead of bumping into a ceiling designed for the average tenant.
A Cleaner Security and Compliance Story
Some security reviews ask a simple question: does any other customer's traffic touch the same broker process? With dedicated hosting the answer is no. That often shortens procurement conversations, even when the shared tier was technically well isolated.
Fewer Constraints on Design
Wide fan-out, many backend consumers on shared subscriptions, larger payloads and QoS 2 flows are all easier to accommodate when the cluster is yours.
Signs You Have Outgrown Serverless
Watch for these signals. One alone is not necessarily a reason to move; several together usually are.
| Signal | What you see | Why it matters |
|---|---|---|
| Connection ceiling | Refused connections, reason code 0x97 | Devices cannot come online |
| Steady, high message rate | Throughput constant all day | You are paying for pooled capacity you effectively always use |
| Latency sensitivity | Control loops, alarms, operator UIs | Variance hurts more than the average |
| Procurement requirements | Questions about shared infrastructure | Isolation simplifies the answer |
| Fleet growth plan | Thousands of devices on the roadmap | Better to migrate before the rush |
| Many backend consumers | Several services subscribing to the same streams | Fan-out multiplies load |
ConnectMQ's Serverless (Paid) plan supports up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions, which is plenty for many products. Dedicated is for when you want your own isolated cluster rather than higher quotas on a shared one.
Capacity Planning for a Dedicated Deployment
Good capacity planning starts from your devices, not from broker benchmarks. Work through these numbers and write them down; they are what you will discuss when sizing your cluster.
- Peak concurrent connections. Devices, gateways, backend services, dashboards and test tools all count. Add the reconnection storm case: after a network outage, every device reconnects within a short window.
- Messages per second, inbound. Multiply devices by publish rate. 2,000 devices at one message every 10 seconds is 200 messages per second on average, but alignment (devices reporting on the minute) creates peaks.
- Fan-out, outbound. Each published message is delivered once per matching subscription. A message read by a dashboard, a historian and an alerting service is three deliveries.
- Payload size. Average and maximum. Compact JSON or binary payloads reduce bandwidth and broker memory.
- QoS mix. QoS 1 and 2 add acknowledgement traffic and in-flight state compared with QoS 0. See MQTT QoS levels explained.
- Session state. Persistent sessions with queued messages for offline clients consume memory. Set session expiry so abandoned sessions do not accumulate.
- Retained messages. One retained message per state topic is cheap; millions of stale retained topics are not.
- Growth. Plan for the next 12 to 18 months of fleet growth rather than today's count.
A simple sizing worksheet in plain text helps align your team:
Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s -> ~200 msg/s inbound
Avg subscribers per message .... 2 -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x
Measure Before You Migrate
Before switching, gather real numbers from your serverless broker. A small Python subscriber that counts messages per top-level topic gives you a quick baseline.
import collections
import ssl
import time
import paho.mqtt.client as mqtt
counts = collections.Counter()
start = time.time()
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("#", qos=0)
def on_message(client, userdata, msg):
counts[msg.topic.split("/")[0]] += 1
elapsed = time.time() - start
if elapsed >= 60:
for prefix, n in counts.most_common():
print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
counts.clear()
globals()["start"] = time.time()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Combine this with the portal dashboard and the $SYS/broker/connection/{clientId}/state topic, which shows whether a given client is connected, to understand both traffic and connection behaviour.
Migration Checklist: Serverless to Dedicated
Because a dedicated MQTT broker speaks the same MQTT 3.1.1 and 5.0 protocol on the same ports (1883, 8883, 8083 and 8084 with /mqtt), migration is mostly a configuration exercise.
- Make the endpoint configurable. If hostname, port, username, password and client ID are compiled into firmware, fix that first. Store them in NVS, a config file or provisioning data.
- Request and provision the dedicated broker. Obtain new credentials from the portal for the dedicated environment.
- Move backend consumers first. Point a copy of each backend service at the new broker and verify it receives test traffic.
- Bridge during transition with your own tool. If devices will move over days or weeks, run a small relay (Node-RED or a short Python script) that subscribes on the old broker and republishes on the new one. ConnectMQ does not provide built-in bridges, so this is done with an external MQTT client.
- Roll devices in waves. Update a small percentage, watch connection state and error logs, then continue.
- Republish retained state. Retained messages do not move automatically; have devices publish their current status on connect.
- Retire the old broker. When the old one shows no device connections, stop the relay and decommission it.
Common pitfalls: forgetting dashboards and scripts that still point at the old hostname, hard-coded client IDs that collide across environments, and missing retained state after cutover. Our MQTT security best practices guide is worth a read at the same time, since migrations are a natural moment to rotate credentials.
Dedicated, BYOC or Enterprise?
Dedicated is not the only isolated option. If your organization needs the broker to run in its own cloud account, BYOC deploys it there while ConnectMQ manages it. If you must operate everything yourself, Self Managed Enterprise covers that. The enterprise MQTT broker guide compares these models against typical enterprise requirements.
Move to a Dedicated Broker with ConnectMQ
Most teams start on the free Serverless plan at app.connectmq.com (no credit card needed), measure real traffic, and move to a Dedicated cluster when isolation and headroom become priorities. ConnectMQ keeps the same protocols, ports and portal tools across plans, so your devices, topic explorer, dashboards and alert rules keep working the same way after the switch.
Frequently Asked Questions
Is a dedicated MQTT broker faster than serverless?
Not necessarily on average, but it is more predictable because no other tenant shares the cluster. The benefit shows most under sustained load and during spikes.
Do I need to rewrite device firmware to move to dedicated?
No, if connection settings are configurable. The protocol and ports stay the same, so only hostname and credentials change.
Can I keep a serverless broker after moving to dedicated?
Yes. Many teams keep a free serverless broker for development and testing and run production on the dedicated cluster.
Does a dedicated broker include replication across regions?
Do not assume it. Ask about the specific deployment, and design devices to reconnect with backoff and republish state so they recover cleanly from any broker restart.
