Public MQTT broker limitations are easy to ignore during the first excited hour of a project and painful to discover in front of a customer. This article explains the four main constraints of public test brokers, using broker.connectmq.com as a concrete example, shows how to design your tests to work within them, and lists the clear signals that it is time to move to a private broker.
Why Public Brokers Have Limits at All
A public broker is a shared, anonymous service. Anyone on the internet can connect, publish and subscribe without an account. That openness is exactly what makes it useful for tutorials and quick tests, and exactly why it needs limits: without them, a single misbehaving script could flood the broker and ruin it for everyone else.
The limits are not a flaw. They are what keeps a free community service usable. ConnectMQ runs broker.connectmq.com for exactly this purpose: a zero-setup place to learn MQTT, test a library or show a demo, alongside private brokers for real workloads. The free public MQTT broker article describes how to use broker.connectmq.com effectively; this article focuses on what it cannot do.
Limitation 1: No Privacy
On a public broker, every topic is readable by every client. A subscriber to # receives everything that is published, subject to the broker's own protections. Topic names are not secrets, and obscure prefixes only reduce accidental collisions.
What this means in practice:
- Never publish personal data, location traces, camera snapshots or anything that identifies a person or home.
- Never publish credentials, API keys or Wi-Fi passwords, even "temporarily".
- Never control real equipment from a public topic. Anyone can publish to your command topic, not only read it.
- Assume payloads are logged by someone, somewhere.
Use a random prefix such as connectmq/demo/9b2e7/ so your test traffic does not collide with others. It is a courtesy and a convenience, not a security measure.
Limitation 2: No Service Guarantees
Public brokers are offered as a best-effort service. There is no SLA, no guaranteed uptime and no support commitment. The broker may restart for maintenance, limits may change, and sessions do not outlive the expiry window. On broker.connectmq.com, session expiry is capped at 30 minutes, so a device that goes offline for longer starts fresh.
For a demo or a workshop, that is fine. For a product, a pilot or anything a customer depends on, it is not.
Plan for Silence
Because there are no guarantees, write your test clients to cope with interruptions. Enable automatic reconnect, resubscribe in the connect callback rather than once at startup, and do not treat a missing message as a bug in your own code until you have ruled out a broker restart. These habits are good practice on any broker and make the later move to production smoother.
Limitation 3: A Shared Topic Space
All public users share one topic tree. Consequences include:
- Collisions. Popular names like
test,sensor/temporhome/livingroomare used by many people. You will receive their messages and they will receive yours. - Retained message surprises. Someone else's retained message on a generic topic will appear the moment you subscribe.
- Wildcard noise. Subscribing broadly returns traffic you never asked for and wastes your rate budget.
Always namespace topics with a unique prefix and subscribe narrowly.
Limitation 4: Rate, Size and Subscription Limits
The public broker caps resources per client so that everyone gets fair access. On broker.connectmq.com the limits are:
| Limit | Public broker value | Why it exists |
|---|---|---|
| Message size | 64 KB per message | Prevents large payloads from dominating bandwidth |
| Publish rate | 10 messages per second per client | Stops scripts from flooding the broker |
| Subscriptions | 10 per client | Limits fan-out cost per client |
| Topic depth | 8 topic levels | Keeps topic matching efficient |
| QoS | 0, 1 and 2 | Full protocol behaviour for learning |
| Session expiry | Up to 30 minutes | Frees resources from abandoned sessions |
| Authentication | Anonymous, any non-empty unique client ID | Zero setup for learners |
Exceeding a limit may lead to rejected operations or a disconnect. If you connect with MQTT 5, log the reason codes your client receives; they tell you far more than a generic "connection lost".
Designing Tests That Respect the Limits
Here is a Python publisher (paho-mqtt 2.x) that stays well inside the public limits: unique client ID, unique prefix, shallow topics, a rate cap and compact payloads.
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN_ID = uuid.uuid4().hex[:6]
PREFIX = f"connectmq/demo/{RUN_ID}" # 3 levels, leaves room below
MAX_RATE = 5 # messages per second, under the 10/s cap
INTERVAL = 1.0 / MAX_RATE
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code, "prefix:", PREFIX)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Disconnected:", reason_code)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=f"limits-demo-{RUN_ID}",
protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
try:
for i in range(50):
payload = json.dumps({"i": i, "t": round(20 + random.random() * 2, 2)})
assert len(payload.encode()) < 64 * 1024
client.publish(f"{PREFIX}/sensor/temp", payload, qos=1)
time.sleep(INTERVAL)
finally:
client.loop_stop()
client.disconnect()
Watch it from a second terminal, subscribing narrowly to your own prefix:
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-RUNID -t "connectmq/demo/RUNID/#" -v
Replace RUNID with the prefix printed by the script.
Common Pitfalls
- Empty client ID. The public broker requires a non-empty client ID. Generate a unique one per run.
- Two scripts with the same client ID. Each connection kicks the other off, producing a reconnect loop.
- Tight publish loops. A
while Trueloop without a sleep exceeds the rate limit within a second. - Deep topic trees.
connectmq/demo/abc/site/area/line/cell/machine/sensoris 9 levels and exceeds the 8-level limit. Flatten test topics. - Large JSON or images. Anything near 64 KB belongs on a private broker, and images rarely belong in MQTT at all.
Signs It Is Time for a Private Broker
Move off the public broker as soon as you notice any of these:
- The data would embarrass or harm anyone if a stranger read it.
- A device acts on commands it receives.
- A customer, colleague or teacher depends on the system working tomorrow.
- You need more than 10 subscriptions per client, larger messages, or deeper topic hierarchies.
- You want to see who is connected and keep credentials per device.
The public vs private MQTT broker comparison walks through the switch, and moving from prototype to production covers the rest of the journey.
What Changes on a Private Plan
A private ConnectMQ broker keeps the same protocol and the same client code, but changes the rules:
- Authentication with a generated username, password and client ID bound to those credentials.
- Isolation from other tenants, so your topic space is yours.
- TLS on 8883 and Secure WebSocket on 8084 with a Let's Encrypt certificate.
- Plan-based limits: the free Serverless plan allows up to 25 connections, QoS up to 1 and 256 KB messages; the paid Serverless plan raises this to up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions.
- Portal tools such as an in-browser client, live topic explorer, dashboard and threshold alerts.
Move to a Private ConnectMQ Broker for Free
When the public broker has done its job, create your free private broker on the Serverless plan, no credit card needed, and point the same script at port 8883 with your new credentials. Read the cloud MQTT broker guide to plan the next steps, see why a managed MQTT service saves operations effort, or visit connectmq.com to compare plans.
Frequently Asked Questions
Is it safe to use a public MQTT broker?
It is safe for learning and demos with harmless data. It is not safe for personal data, credentials or controlling real equipment, because anyone can read and publish to any topic.
What happens if I exceed the public broker's rate limit?
Operations may be rejected or the client disconnected. Keep publishing below 10 messages per second per client and check MQTT 5 reason codes when debugging.
Why do I receive messages I did not publish?
Other users publish to the same topic names. Use a unique prefix such as connectmq/demo/<random-id>/ and subscribe only to that prefix.
Does the public broker keep my session if my device goes offline?
Only within the session expiry window, which is capped at 30 minutes on broker.connectmq.com. After that, the device starts a fresh session.
