Open-Source-MQTT-Broker im Vergleich: Mosquitto, EMQX, VerneMQ und NanoMQ

Dieser Open-Source-MQTT-Broker-Vergleich betrachtet vier weit verbreitete Projekte, Eclipse Mosquitto, EMQX, VerneMQ und NanoMQ, aus der Sicht von jemandem, der sie betreiben muss. Sie erfahren, worin jeder Broker gut ist, welchen Betriebsaufwand er Ihnen abverlangt und wie Sie jeden davon in wenigen Minuten lokal starten. Am Ende sollten Sie wissen, welcher zu Ihrem Projekt passt oder ob es sich eher lohnt, den Betrieb einem verwalteten MQTT-Broker zu überlassen.

Warum Open-Source-MQTT-Broker überhaupt vergleichen?

Jede MQTT-Bereitstellung braucht einen Broker: den Server, der Verbindungen annimmt, Clients authentifiziert und jede veröffentlichte Nachricht an alle passenden Subscriber weiterleitet. Wenn Sie diese Rolle auffrischen möchten, lesen Sie, was ein MQTT-Broker leistet. Das Protokoll ist standardisiert, sodass jeder konforme Client mit jedem konformen Broker sprechen kann. Was sich zwischen den Brokern unterscheidet, ist alles rund um das Protokoll: wie sie skalieren, wie sie Sessions speichern, wie Sie die Authentifizierung konfigurieren, wie sie sich bei Upgrades verhalten und wie viel Ihrer Zeit sie beanspruchen.

Alle vier folgenden Projekte sind ausgereift, irgendwo produktiv im Einsatz und implementieren MQTT 3.1.1 und MQTT 5.0. Keines davon ist abstrakt „das beste". Die richtige Wahl hängt von der Anzahl der Verbindungen ab, davon, ob Sie Clustering brauchen, was Ihr Team bereits kennt und welche Lizenzbedingungen Ihre Organisation akzeptiert.

Die vier Broker im Überblick

Eclipse Mosquitto

Mosquitto ist der Bezugspunkt, mit dem die meisten beginnen. Er ist in C geschrieben, wird unter dem Dach der Eclipse Foundation gepflegt und ist klein genug, um auf einem Raspberry Pi oder in einem Container mit wenigen Megabyte Speicher zu laufen. Die Konfiguration ist eine einzige Textdatei, die Authentifizierung erfolgt über eine Passwortdatei oder das Dynamic-Security-Plugin, und per Bridging kann eine Mosquitto-Instanz Topics an einen anderen Broker weiterleiten.

Die wesentliche architektonische Grenze: Mosquitto läuft als einzelner Knoten. Es gibt kein eingebautes Clustering, Hochverfügbarkeit bedeutet also eine externe Failover-Lösung und einen Plan für den Session-Zustand. Für einen einzelnen Standort, ein Labor, ein Edge-Gateway in der Werkhalle oder einige tausend Geräte auf einem gut dimensionierten Server ist das oft völlig ausreichend.

EMQX

EMQX basiert auf Erlang/OTP und wurde von Anfang an für Clustering konzipiert. Mehrere Knoten bilden einen logischen Broker, wodurch sich sehr große Verbindungszahlen auf mehrere Maschinen verteilen lassen. Zum Funktionsumfang gehören ein Web-Dashboard, ein umfangreiches Authentifizierungs- und Autorisierungssystem sowie eine eingebaute Rule Engine und Datenintegrationen. Für Cluster-Bereitstellungen steht ein Kubernetes-Operator zur Verfügung.

Die Lizenzierung verdient Aufmerksamkeit: EMQX hat sein Lizenzmodell über mehrere Releases hinweg geändert, und die Bedingungen der neuesten Versionen unterscheiden sich von älteren Open-Source-Releases. Lesen Sie die aktuelle Lizenz auf der EMQX-Website und stellen Sie sicher, dass sie zu Ihrem Einsatz passt, bevor Sie darauf standardisieren.

VerneMQ

VerneMQ basiert ebenfalls auf Erlang und bietet masterloses Clustering, Plugin-Hooks für Authentifizierung und Autorisierung sowie Funktionen wie Mountpoints zur Trennung von Topic-Bereichen. Der Quellcode ist unter der Apache-2.0-Lizenz veröffentlicht. Die offiziellen vorgefertigten Pakete und Container-Images haben eigene Bedingungen (das Docker-Image verlangt, eine EULA über eine Umgebungsvariable zu akzeptieren); prüfen Sie also, welche Distribution Sie verwenden. Wie bei jedem Projekt sollten Sie sich vor einer Festlegung die jüngste Release-Aktivität und die Support-Kanäle der Community ansehen.

NanoMQ

NanoMQ vom EMQ-Team ist ein schlanker Broker in C auf Basis der Messaging-Bibliothek NNG. Er zielt auf Edge-Geräte und Gateways: geringer Ressourcenbedarf, Multi-Threading-Leistung auf bescheidener Hardware und Bridging zu einem übergeordneten Broker. Er passt gut, wenn Sie auf einem Industrie-PC oder Gateway einen lokalen Broker möchten, der ausgewählte Topics an einen zentralen oder Cloud-Broker weiterleitet.

Vergleichstabelle zu Funktionen und Betrieb

Die Tabelle fasst Architektur und typische Betriebsmerkmale zusammen. Prüfen Sie Details stets anhand der aktuellen Dokumentation jedes Projekts, da sich Funktionen zwischen Releases verschieben.

Zwei Beobachtungen stechen hervor. Erstens sind Single-Node-Broker einfacher zu betreiben, zwingen Sie aber, die Verfügbarkeit selbst zu lösen. Zweitens lösen geclusterte Broker Verfügbarkeit und Skalierung, bringen aber zusätzliche bewegliche Teile mit: Knotenerkennung, Netzwerkpartitionen, Rolling Upgrades und clusterfähiges Monitoring.

Jeden Broker lokal mit Docker ausprobieren

Am schnellsten bilden Sie sich eine Meinung, indem Sie jeden Broker starten und einen Client verbinden. Die folgenden Befehle dienen nur dem lokalen Test, mit aktiviertem anonymen Zugriff. Stellen Sie diese Setups nicht ins Internet.

# Mosquitto 2.x braucht einen expliziten Listener, um Verbindungen von außerhalb von localhost anzunehmen
mkdir -p mosquitto/config
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run -d --name mosquitto -p 1883:1883 \
  -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2

# EMQX (Dashboard unter http://localhost:18083)
docker run -d --name emqx -p 1884:1883 -p 18083:18083 emqx/emqx:latest

# VerneMQ (Image-EULA akzeptieren und anonymen Zugriff für einen lokalen Test erlauben)
docker run -d --name vernemq -p 1885:1883 \
  -e DOCKER_VERNEMQ_ACCEPT_EULA=yes \
  -e DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on vernemq/vernemq

# NanoMQ
docker run -d --name nanomq -p 1886:1883 emqx/nanomq:latest

Führen Sie dann denselben Publish-und-Subscribe-Test gegen jeden Port aus:

for port in 1883 1884 1885 1886; do
  mosquitto_sub -h localhost -p $port -i sub-$port -t 'test/compare' -C 1 -W 5 &
  sleep 1
  mosquitto_pub -h localhost -p $port -i pub-$port -t 'test/compare' -m "hello from $port"
  wait
done

Jeder Subscriber sollte eine Nachricht ausgeben und sich beenden. Sobald das funktioniert, beginnt der interessante Teil: Aktivieren Sie die Authentifizierung, fügen Sie TLS hinzu, starten Sie den Container neu, während ein Client eine persistente Session hält, und sehen Sie, was überlebt. Diese Übung verrät Ihnen mehr über den laufenden Betrieb als jede Funktionsliste.

Was die Funktionsliste Ihnen nicht verrät

TLS und Zertifikate

Jeder Broker unterstützt TLS, aber jemand muss Zertifikate beschaffen, sie vor Ablauf erneuern und den Broker neu laden, ohne alle Geräte zu trennen. Das mit ACME-Tools zu automatisieren ist gut machbar und zugleich eine klassische Ausfallursache, wenn ein Erneuerungsjob unbemerkt fehlschlägt.

Upgrades und langlebige Verbindungen

MQTT-Verbindungen bestehen über Tage oder Monate. Ein Neustart eines Single-Node-Brokers trennt alle Clients auf einmal, und alle verbinden sich im selben Moment neu. Geclusterte Broker können Upgrades Knoten für Knoten durchführen, doch die Clients auf dem neu startenden Knoten verbinden sich trotzdem neu. Planen Sie unabhängig vom gewählten Broker ein randomisiertes Reconnect-Backoff auf Geräteseite ein.

Monitoring und Kapazität

Sie müssen Verbindungszahlen, Nachrichtenraten, verworfene Nachrichten, Speicher und File Descriptors beobachten. Mosquitto veröffentlicht Statistiken unter $SYS/-Topics; die geclusterten Broker stellen HTTP-APIs und Metrik-Endpunkte bereit. So oder so bauen Sie Dashboards und Alarmregeln selbst. Unser Leitfaden zum Monitoring von MQTT-Brokern listet die Metriken auf, die sich zu verfolgen lohnen.

Sicherheitsbetrieb

Offene MQTT-Ports ziehen schnell Scanner an. Härtung bedeutet, anonymen Zugriff zu deaktivieren, fehlgeschlagene Anmeldungen zu drosseln, Broker und Basis-Image aktuell zu halten und die Konfiguration nach jedem Upgrade zu überprüfen. Der Artikel zu MQTT-Sicherheits-Best-Practices behandelt die Client-Seite dieses Bildes.

Wie Sie zwischen ihnen wählen

Nutzen Sie diese Fragen als Entscheidungspfad:

1. Wie viele gleichzeitige Verbindungen erwarten Sie in zwei Jahren? Deckt ein gut ausgestatteter Server sie bequem ab, hält Mosquitto das Leben einfach. Wenn nicht, sehen Sie sich geclusterte Optionen an.
2. Brauchen Sie den Broker am Edge? Für Gateways und Industrie-PCs sind Mosquitto oder NanoMQ naheliegende Optionen, meist mit Bridging zu einem zentralen Broker. In Industrie-4.0-Projekten ist dieser zentrale Broker häufig der Knoten eines Unified Namespace (UNS), dessen Topics der ISA-95-Hierarchie folgen, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur.
3. Ist Hochverfügbarkeit eine harte Anforderung? Dann betreiben Sie entweder einen geclusterten Broker oder entwerfen ein externes Failover für einen Single-Node-Broker, einschließlich der Frage, was mit persistenten Sessions geschieht.
4. Welche Lizenzbedingungen kann Ihre Organisation akzeptieren? Lesen Sie die aktuelle Lizenz genau der Version und Distribution, die Sie bereitstellen werden.
5. Wer hat Rufbereitschaft? Ein Broker ist Infrastruktur. Wenn niemand im Team Patches, Zertifikate und Alarme um 3 Uhr nachts übernehmen möchte, berücksichtigen Sie das jetzt.

Wenn Sie bei Frage fünf ins Grübeln kommen, vergleichen Sie den Aufwand mit einer Analyse MQTT-Broker selbst betrieben vs. verwaltet, bevor Sie entscheiden.

Wann ein verwalteter MQTT-Broker sinnvoller ist

Open-Source-Broker sind hervorragende Software. Die Kosten ihres Betriebs bestehen vor allem aus der Zeit von Menschen: TLS einrichten, Monitoring aufbauen, Upgrades durchführen, Limits abstimmen und auf Störungen reagieren. Für viele IoT-Teams ist diese Zeit bei Geräten und Anwendungen besser investiert.

Ein verwalteter MQTT-Broker verlagert diese Aufgaben zum Anbieter. Mit ConnectMQ erstellen Sie einen Broker im Portal und erhalten einen Benutzernamen, ein Passwort und eine Client-ID. Die Endpunkte stehen auf TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084 (Pfad /mqtt) mit einem Let's-Encrypt-Zertifikat bereit, und sowohl MQTT-3.1.1- als auch MQTT-5.0-Clients funktionieren unverändert. Da MQTT ein Standard ist, verbindet sich derselbe Client-Code, den Sie gegen Mosquitto oder EMQX getestet haben, mit ConnectMQ, indem Sie nur Host, Port und Zugangsdaten ändern.

ConnectMQ ergänzt außerdem Tools, die Sie sonst selbst zusammenstellen müssten: einen MQTT-Client im Browser, einen Live-Topic-Explorer, ein Dashboard, eine nach ISA-95-Ebenen geordnete Geräteansicht und Schwellwert-Alarmregeln mit Alarmprotokoll. Die Tarife reichen von einem kostenlosen Serverless-Tarif auf einem geteilten Cluster über isolierte Dedicated-Cluster bis zu BYOC in Ihrem eigenen Cloud-Konto, sodass das Hosting-Modell Ihren Anforderungen folgen kann. Der Leitfaden zum Cloud-MQTT-Broker erklärt, wie sich diese Modelle vergleichen.

Ein sinnvolles Muster ist hybrid: Behalten Sie Mosquitto oder NanoMQ am Edge für lokale Ausfallsicherheit und leiten Sie ausgewählte Topics per Bridge an einen verwalteten MQTT-Broker weiter, den Ihre Cloud-Anwendungen und Dashboards nutzen. Bei mehreren Werken entsteht so ein standortübergreifender UNS: Jedes Werk speist seinen ISA-95-Zweig ein, und MES, ERP und Analytics abonnieren zentral. Mehr dazu im Artikel zu Sparkplug B und Unified Namespace.

In wenigen Minuten gegen einen gehosteten Broker testen

Bevor Sie wählen, richten Sie Ihren bestehenden Client auf einen gehosteten Broker aus und vergleichen Sie die Erfahrung mit Ihren lokalen Containern. Der kostenlose öffentliche MQTT-Broker unter broker.connectmq.com benötigt kein Konto; verwenden Sie eine eindeutige Client-ID und ein eindeutiges Topic-Präfix und denken Sie daran, dass öffentliche Topics für jeden lesbar sind.

mosquitto_sub -h broker.connectmq.com -p 1883 -i cmp-sub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -v &
mosquitto_pub -h broker.connectmq.com -p 1883 -i cmp-pub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -m 'hello from the comparison test'

Für Produktionsdaten erstellen Sie einen privaten Broker und verbinden sich über TLS auf Port 8883 mit Ihren eigenen Zugangsdaten.

Starten Sie mit ConnectMQ

Wenn Sie Ihre Zeit lieber in Geräte und Anwendungen als in den Broker-Betrieb investieren, erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com. Eine Kreditkarte ist nicht erforderlich, und Sie können später auf Dedicated oder BYOC wechseln, ohne Ihren MQTT-Client-Code zu ändern.

Häufig gestellte Fragen

Welcher Open-Source-MQTT-Broker eignet sich am besten für Einsteiger?

Mosquitto ist meist der einfachste Einstieg. Er ist in Minuten installiert, nutzt eine einzige gut lesbare Konfigurationsdatei und ist in unzähligen Tutorials dokumentiert.

Kann Mosquitto geclustert werden?

Nicht nativ. Mosquitto läuft als einzelner Knoten; Sie können Instanzen per Bridge verbinden oder ein externes Failover aufbauen, doch für einen echten Multi-Node-Cluster sollten Sie einen Broker wählen, der für Clustering konzipiert ist.

Ist EMQX noch Open Source?

Die Lizenzierung von EMQX hat sich über mehrere Releases geändert, die Antwort hängt also von der eingesetzten Version ab. Prüfen Sie die Lizenz, die mit genau dem Release veröffentlicht wurde, das Sie nutzen möchten.

Kann ich später von einem Open-Source-Broker zu einem verwalteten MQTT-Broker wechseln?

Ja. MQTT ist ein Standard, Clients brauchen also meist nur einen neuen Host, Port und neue Zugangsdaten. Prüfen Sie Broker-spezifische Funktionen, auf die Sie sich verlassen, etwa Rule Engines oder Plugins, denn diese ziehen nicht automatisch mit um.