Die Wahl eines MQTT Brokers für Startups ist ein anderes Problem als für ein etabliertes Unternehmen: Sie brauchen heute etwas Kostenloses oder nahezu Kostenloses, das sich schnell integrieren lässt und das Sie leicht verlassen oder skalieren können, wenn das Geschäft abhebt. Dieser Leitfaden bietet IoT-Teams in der Frühphase einen praxisnahen Entscheidungsprozess, ein Firmware-Design, das Sie portabel hält, und einen gestuften Plan vom kostenlosen ConnectMQ Serverless Broker bis zu dedizierter Kapazität.
Was Startups wirklich von einem Broker brauchen
Die Engpässe eines Startups sind Zeit, Geld und Unsicherheit. Sie wissen noch nicht, ob Sie nächstes Jahr fünfzig oder fünfzigtausend Geräte haben, welche Protokolle die IT- und OT-Teams Ihrer Kunden akzeptieren (bei Maschinenbauern und im Mittelstand oft eine harte Hürde) oder welche Funktionen Ihres Produkts den Kontakt mit dem Markt überstehen. Daraus ergibt sich eine kurze Liste von Anforderungen:
- Kein Betriebsaufwand. Jede Stunde, die Sie mit dem Patchen einer Broker-VM verbringen, fehlt beim Produkt. Ein verwalteter MQTT-Broker nimmt Ihnen diese Arbeit ab.
- Kostenlos oder sehr günstig im kleinen Maßstab. Ihr MVP sollte keine Infrastrukturkosten tragen, die für produktive Flotten gedacht sind.
- Standardprotokoll, kein proprietäres SDK. Reines MQTT 3.1.1 und 5.0 bedeutet, dass jede Bibliothek auf jedem Gerät funktioniert und Sie später den Anbieter wechseln können.
- TLS und Zugangsdaten ab Tag eins. Nachträgliche Sicherheitsumbauten sind teuer; beginnen Sie mit verschlüsselten Verbindungen.
- Ein sichtbarer Wachstumspfad. Sie möchten wissen, was bei 25, 1.000 und 10.000 Verbindungen passiert, bevor Sie dort ankommen.
Optionen im Vergleich
| Option | Anfangsaufwand | Kosten in der MVP-Phase | Lock-in-Risiko | Hinweise |
|---|---|---|---|---|
| Öffentlicher MQTT-Broker | Keiner | Kostenlos | Keines | Ideal für Demos, nie für Kundendaten |
| Selbst gehosteter Mosquitto auf einer VM | Mittel | Geringe VM-Kosten plus Ihre Zeit | Gering | Patches, TLS, Monitoring und Ausfälle liegen bei Ihnen |
| Cloud-IoT-Plattform mit proprietärem SDK | Mittel | Unterschiedlich | Hoch | Gerätecode an Hersteller-APIs gebunden |
| Verwalteter MQTT-Broker (Serverless) | Gering | Kostenlose Stufe verfügbar | Gering bei Standard-MQTT | Kontingente bestimmen den Zeitpunkt des Upgrades |
Für die meisten jungen Teams lautet die richtige Antwort: ein verwalteter MQTT-Broker im Serverless-Modell für alles Ernsthafte und ein öffentlicher MQTT-Broker für Wegwerf-Experimente. Der Öffentliche MQTT-Broker unter broker.connectmq.com ist für Tests und Prototypen gedacht und ideal für einen ersten Spike: anonym, mit einer beliebigen, nicht leeren, eindeutigen Client ID und Topics unter einem eindeutigen Präfix wie connectmq/demo/k29xq/.... Da dort alles für jeden lesbar ist, wechseln Sie zu einem privaten Broker, sobald Daten eines Pilotkunden im Spiel sind.
Der Plan, Stufe für Stufe
Stufe 1: Spike (Tage)
Nutzen Sie den öffentlichen MQTT-Broker, um die Kette vom Gerät bis zum Dashboard zu beweisen. Prüfen Sie Topics mit mosquitto_pub und mosquitto_sub:
mosquitto_sub -h broker.connectmq.com -p 1883 -i spike-sub-k29xq -t 'connectmq/demo/k29xq/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i spike-pub-k29xq \
-t 'connectmq/demo/k29xq/dev1/telemetry' -m '{"temp":22.4}'
Stufe 2: MVP und Piloten (Wochen bis Monate)
Erstellen Sie einen kostenlosen ConnectMQ Serverless Broker. Er unterstützt bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB, was für eine Handvoll Piloteinheiten, einen Backend-Worker und ein paar Dashboards reicht. Sie erhalten TLS auf 8883, WebSocket auf 8083 und 8084, einen Client im Browser, einen Topic-Explorer, ein Dashboard und Schwellenwert-Alarmregeln, was oft genügt, um Investoren eine Demo zu zeigen, ohne eine eigene Admin-Oberfläche zu bauen.
Stufe 3: Erste Umsätze (Hunderte Geräte)
Wechseln Sie zu Serverless (Paid): bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions, sodass sich mehrere Backend-Worker mit $share/workers/devices/+/telemetry einen Stream teilen können. Lesen Sie MQTT-QoS-Stufen erklärt, bevor Sie QoS 2 überall einschalten; für die meiste Telemetrie reicht QoS 1.
Stufe 4: Skalierung und Großkunden
Wenn Sie Isolation, planbare Reserven oder Antworten für eine Sicherheitsprüfung brauchen, wechseln Sie zu einem dedizierten MQTT Broker. Besteht ein Großkunde darauf, dass der Broker in seinem Cloud-Konto läuft, deckt BYOC das ab, während ConnectMQ ihn weiterhin betreibt.
Von Anfang an auf Portabilität auslegen
Lock-in entsteht selten durch den Broker selbst, sondern durch Abkürzungen in Firmware und Backend. Diese Gewohnheiten halten Ihnen den Wechsel offen.
Verbindungseinstellungen aus dem Code heraushalten
Kompilieren Sie Hostname und Zugangsdaten nie als unveränderliche Konstanten in die Firmware. Provisionieren Sie sie bei der Fertigung oder über einen sicheren Onboarding-Ablauf und legen Sie sie im nichtflüchtigen Speicher ab. Hier ein minimales Muster für einen ESP32 mit der Preferences-Bibliothek:
#include <Preferences.h>
struct MqttConfig {
String host;
uint16_t port;
String user;
String pass;
String clientId;
};
MqttConfig loadMqttConfig() {
Preferences prefs;
prefs.begin("mqtt", true); // nur lesend
MqttConfig cfg;
cfg.host = prefs.getString("host", "broker.connectmq.com");
cfg.port = prefs.getUShort("port", 8883);
cfg.user = prefs.getString("user", "");
cfg.pass = prefs.getString("pass", "");
cfg.clientId = prefs.getString("cid", "");
prefs.end();
return cfg;
}
void saveMqttConfig(const MqttConfig& cfg) {
Preferences prefs;
prefs.begin("mqtt", false);
prefs.putString("host", cfg.host);
prefs.putUShort("port", cfg.port);
prefs.putString("user", cfg.user);
prefs.putString("pass", cfg.pass);
prefs.putString("cid", cfg.clientId);
prefs.end();
}
Damit wird der Wechsel von einem Serverless zu einem dedizierten Broker oder gleich zu einem anderen Anbieter zu einem Konfigurations-Push statt zu einem Firmware-Release.
Reines MQTT statt Hersteller-SDK verwenden
Bleiben Sie bei verbreiteten offenen Bibliotheken: PubSubClient oder AsyncMqttClient auf dem ESP32, paho-mqtt in Python, MQTT.js in Node.js und im Browser. Sie funktionieren mit jedem standardkonformen Broker.
Die Topic-Struktur selbst bestimmen
Gestalten Sie Topics entlang Ihrer Domäne, nicht entlang Ihres Anbieters: acme/{customerId}/{siteId}/{deviceId}/telemetry. Verkaufen Sie an Fertigungsbetriebe, lohnt sich die Orientierung an ISA-95: Die Anlagenhierarchie aus Enterprise, Site, Area, Line und Cell wird zur Topic-Struktur eines Unified Namespace (UNS) auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Industriekunden finden darin ihre eigene Struktur wieder, was die Anbindung an MES und ERP erleichtert; mehr dazu im Beitrag Sparkplug B und Unified Namespace. Unser Leitfaden wie Sie einen IoT MQTT Broker auswählen behandelt weitere Bewertungskriterien, und eine gute Topic-Struktur übersteht jeden Broker-Wechsel.
Integrationen außerhalb des Brokers halten
Schreiben Sie Telemetrie mit Ihrem eigenen Subscriber-Service, einem Node-RED-Flow oder Telegraf in Ihre Datenbank. Diese Logik zieht mit Ihnen um. ConnectMQ lässt den Broker bewusst einen Broker sein; Integrationen laufen als normale MQTT-Clients, was zufällig genau das portable Muster ist, das Sie ohnehin wollen.
Typische Fehler von Startups
- Demo-Geräte ausliefern, die auf einen öffentlichen MQTT-Broker zeigen. Das funktioniert, bis ein Kunde bemerkt, dass seine Daten für alle lesbar sind.
- Ein gemeinsamer Benutzername für alle Geräte. Sie können keine einzelne kompromittierte Einheit sperren. Verwenden Sie getrennte Zugangsdaten oder zumindest eigene Client IDs pro Gerät.
- Doppelte Client IDs. Zwei Geräte mit derselben ID trennen sich gegenseitig in einer Endlosschleife.
- Kein Reconnect-Backoff. Nach einem Ausfall bestürmt jedes Gerät gleichzeitig den Broker. Ergänzen Sie exponentielles Backoff mit Jitter.
- QoS 2 als „zuverlässiger, also immer besser“ behandeln. Es fügt Roundtrips und Zustand hinzu; machen Sie Konsumenten idempotent und verwenden Sie QoS 1.
- Riesige Payloads. Senden Sie Bilder oder Logs an einen Objektspeicher und publizieren Sie eine Referenz.
- Kein Status-Topic. Nutzen Sie eine Last-Will-Nachricht und ein retained Status-Topic, damit Ihr Dashboard weiß, welche Geräte offline sind.
Eine einfache Entscheidungs-Checkliste
Beantworten Sie diese Fragen im Team, bevor Sie sich festlegen:
- Können wir in weniger als einer Stunde einen Broker anlegen und ein Gerät per TLS verbinden?
- Ist das Protokoll reines MQTT 3.1.1 oder 5.0 ohne verpflichtendes SDK?
- Sind die Limits der kostenlosen Stufe dokumentiert, und wissen wir, welches wir zuerst erreichen?
- Gibt es einen klaren Upgrade-Pfad zu mehr Verbindungen und dann zu isolierter Kapazität?
- Könnten wir allein durch Konfigurationsänderungen zu einem anderen Broker wechseln?
- Bietet das Portal genug Einblick (Topic-Explorer, Dashboard, Alarme), damit wir am ersten Tag nichts Eigenes bauen müssen?
Wenn alle Antworten Ja lauten, haben Sie einen Broker, der zu einem Startup passt. Einen breiteren Blick auf Hosting-Modelle bietet unser Leitfaden zum Cloud-MQTT-Broker.
Starten Sie Ihr MVP auf ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless Broker, ganz ohne Kreditkarte. Sie erhalten in wenigen Minuten Zugangsdaten, TLS- und WebSocket-Endpunkte sowie Portal-Werkzeuge, um Ihr Produkt vorzuführen. Wenn die Flotte wächst, bietet ConnectMQ die Pläne Serverless (Paid), Dedicated und BYOC auf demselben Standardprotokoll an, sodass Skalierung ein Upgrade ist und keine Neuentwicklung.
Häufig gestellte Fragen
Welcher MQTT Broker ist der beste für Startups mit knappem Budget?
Ein verwalteter MQTT-Broker mit einer wirklich kostenlosen Stufe und Unterstützung für Standard-MQTT, sodass Sie während des MVP nichts zahlen und keinen Betriebsaufwand haben. Ein kostenloser Serverless-Plan unterstützt zum Beispiel bis zu 25 Verbindungen mit TLS.
Sollte ein Startup stattdessen Mosquitto selbst hosten?
Das ist möglich, doch dann liegen Patches, Zertifikate, Monitoring und Ausfälle bei Ihnen. Die meisten kleinen Teams gewinnen mehr, wenn sie diese Zeit ins Produkt stecken.
Wie vermeiden wir Vendor-Lock-in bei einem MQTT Broker?
Verwenden Sie reine MQTT-Bibliotheken, halten Sie Verbindungseinstellungen konfigurierbar, entwerfen Sie Ihre eigene Topic-Struktur und betreiben Sie Integrationen als externe Subscriber.
Wann sollte ein Startup zu einem dedizierten Broker wechseln?
Wenn Sie sich den Verbindungskontingenten nähern, unter gleichmäßiger Last vorhersehbare Performance brauchen oder die Sicherheitsprüfung eines Kunden isolierte Infrastruktur verlangt.
