EMQX vs. Mosquitto: Welcher MQTT-Broker für dein IoT?

Ein MQTT-Broker entscheidet oft leiser, als man denkt, über Stabilität, Latenz und Wartungsaufwand eines IoT-Systems. EMQX und Eclipse Mosquitto lösen dieselbe Grundaufgabe, setzen aber an sehr unterschiedlichen Punkten an: der eine eher als skalierbare Plattform für verteilte Lasten, der andere als schlanker Broker für einfache, robuste Installationen. In diesem Artikel ordne ich die Unterschiede ein, zeige die praktischen Stärken beider Lösungen und mache klar, wann ich welches System für ein IoT-Setup wählen würde.

Worum es bei der Entscheidung wirklich geht

Ich sehe den Vergleich nicht als reine Protokollfrage, sondern als Betriebsfrage. Die eigentliche Frage lautet nicht, ob beide MQTT können, sondern wie viel Komplexität dein System verträgt und wie viel Kontrolle du im Alltag brauchst. Bei einem einzelnen Standort mit überschaubarer Last genügt oft ein schlanker Broker. Sobald mehrere Standorte, strengere Zugriffsregeln, Monitoring und Ausfallsicherheit dazukommen, verschiebt sich der Schwerpunkt schnell.

Für IoT-Systeme in der Telekommunikation und Infrastruktur denke ich dabei besonders an entfernte Sensoren, Energieanlagen, Wassertechnik, Logistikpunkte oder Funkstandorte mit nicht immer stabiler Verbindung. Genau dort zählt nicht nur die Nachricht selbst, sondern auch, wie sauber der Broker mit Unterbrechungen, Wiederverbindungen und administrativer Pflege umgeht. Dieser Blickwinkel führt direkt zur Architekturfrage.

Architektur und Betriebsmodell unterscheiden sich deutlich

EMQX als verteilte Plattform

EMQX ist auf verteilte Betriebsmodelle ausgelegt. Laut offizieller Dokumentation arbeiten in einem Cluster mehrere Knoten zusammen, um Nachrichten zu routen, MQTT-Sessions zu verwalten und Hochverfügbarkeit zu sichern. Das ist vor allem dann stark, wenn ich einen zentralen Broker brauche, der nicht nur Nachrichten annimmt, sondern auch gemeinsam mit anderen Knoten wächst, ausfälltolerant bleibt und sich administrativ bündeln lässt.

Was mir daran gefällt: Die Plattform denkt Betrieb mit. Ein Dashboard, eine API und Cluster-Mechanismen nehmen dir nicht die Architekturentscheidung ab, aber sie reduzieren den manuellen Aufwand im Alltag. In größeren Teams ist das oft mehr wert als jede einzelne Feature-Liste, weil Fehlersuche, Rechteverwaltung und Monitoring schneller werden.

Lesen Sie auch: MQTT vs. WebSocket im IoT - Was ist besser und warum?

Mosquitto als schlanker Einzelbroker

Mosquitto verfolgt eine andere Philosophie. Die offizielle Projektseite beschreibt ihn als leichten Open-Source-Broker, geeignet vom Einplatinenrechner bis zum Server. Für mich ist das der Broker für Situationen, in denen Einfachheit ein echter Vorteil ist: wenig Ressourcen, klare Konfiguration, kurze Wege. Er passt sehr gut an den Rand eines Netzes, auf Gateways oder an lokale Standorte, an denen der Dienst einfach zuverlässig laufen soll.

Mosquitto kann mehrere Broker über Bridges verbinden. Eine Bridge ist eine Kopplung zwischen Brokern, mit der Nachrichten zwischen getrennten Systemen weitergereicht werden. Das ist nützlich, ersetzt aber kein tief integriertes Cluster-Modell wie bei EMQX. Genau hier liegt der Kern des Vergleichs: EMQX bringt Verteilung als Kernprinzip mit, Mosquitto eher als einfache, kontrollierbare Kopplung. Von dort aus lohnt sich der Blick auf die Funktionen im Detail.

Leistungsumfang im direkten Vergleich

Wenn ich die Tabelle auf eine Aussage verdichten müsste, wäre es diese: Mosquitto gewinnt bei Einfachheit, EMQX bei Betriebsfunktionen. Das ist kein kleiner Unterschied, sondern oft der Punkt, an dem ein Projekt entweder angenehm bleibt oder im Alltag immer mehr Handarbeit erzeugt. Die Sicherheitsfrage ist dabei der nächste große Stolperstein.

Sicherheit und Zugriffssteuerung richtig einordnen

Bei beiden Brokern gilt: Produktiv ohne sauberes Sicherheitskonzept ist keine gute Idee. Die Mosquitto-Dokumentation macht ausdrücklich klar, dass der einfachste Zustand auch komplett ohne Authentifizierung sein kann, wenn man nichts anderes konfiguriert. EMQX ist ebenfalls nicht automatisch in einer produktionsreifen Härtung aktiviert. Das ist nicht ungewöhnlich, aber es heißt: Sicherheit ist eine Konfigurationsaufgabe, keine Nebenfunktion.

In der Praxis schaue ich auf drei Ebenen:

• Authentifizierung beantwortet die Frage, wer sich verbinden darf. EMQX unterstützt dafür mehrere Mechanismen, darunter Zertifikate, JWT, Benutzer/Passwort und PSK. Mosquitto bietet Passwortdateien, Dynamic Security und Auth-Plugins.
• Autorisierung regelt, was ein Client lesen oder schreiben darf. ACLs sind dabei Zugriffslisten, also Regeln pro Topic oder Rolle.
• Transportverschlüsselung schützt den Weg der Nachrichten. Wenn Passwörter im Spiel sind, muss TLS immer mitgedacht werden; sonst ist der Schutz nur auf dem Papier stark.

Besonders sauber wird es, wenn Geräte Zertifikate unterstützen. Mutual TLS, kurz mTLS, bedeutet, dass sich Client und Broker gegenseitig per Zertifikat ausweisen. Das ist administrativ etwas aufwendiger, aber für viele feste IoT-Geräte deutlich robuster als reine Passwörter. Wenn Zertifikate im Feld nicht praktikabel sind, würde ich wenigstens auf TLS mit klaren Rollen, Rotation der Zugangsdaten und eng definierten Topics setzen. Von dort ist es nur noch ein Schritt zur Frage, wie gut das System unter Last und bei Ausfällen funktioniert.

Skalierung und Zuverlässigkeit in verteilten IoT-Netzen

Gerade in Infrastrukturprojekten mit entfernten Standorten, wechselnder Leitungsqualität und knappen Wartungsfenstern trennt sich die Spreu vom Weizen. EMQX ist hier stark, weil Cluster nicht als Zusatz, sondern als Kern des Designs gedacht sind. In der Dokumentation wird die horizontale Skalierung sehr weit nach oben beschrieben, inklusive sehr großer Verbindungszahlen in Enterprise-Setups. Ich lese das nicht als Versprechen für jedes Projekt, aber als klares Signal: Dieses System ist für Wachstum gebaut.

Mosquitto spielt seine Stärke aus, wenn das Netz zwar verteilt, aber die lokale Aufgabe klar begrenzt ist. Ein schlanker Broker auf einem Gateway oder einem kleinen Server kann vor Ort sehr zuverlässig arbeiten, ohne dass du viel Infrastruktur mitziehen musst. Bridges helfen dann, getrennte Bereiche zu verbinden, etwa einen Standort im Feld mit einer zentralen Plattform im Kernnetz. Das ist nützlich, aber es bleibt ein anderes Modell als ein einheitliches Cluster.

Für Timor-Leste-ähnliche Szenarien mit auseinandergezogenen Standorten, unterschiedlichen Leitungsqualitäten und begrenzter Vor-Ort-Wartung würde ich genau darauf achten, wo der Broker steht. Ein zentraler Knoten kann in solchen Netzen schnell zur Abhängigkeit werden. Ein lokaler Broker am Rand, der den Standort selbständig bedient, und eine zentrale Instanz für Aggregation und Analyse ergeben oft die bessere Betriebslogik.

• Ein Messnetz mit einigen hundert Geräten und einem Standort lässt sich meist sauber mit Mosquitto aufsetzen.
• Ein Projekt mit mehreren tausend Verbindungen, mehreren Standorten und zentralem Monitoring wird mit EMQX deutlich angenehmer.
• Ein Hybridmodell ist oft die pragmatischste Lösung, wenn lokale Verfügbarkeit und zentrale Auswertung gleichzeitig wichtig sind.

Damit wird klar: Skalierung ist nicht nur eine Frage von Megabyte und Verbindungen, sondern vor allem von Betriebsrealität. Genau daraus leite ich auch die Auswahl für typische Projekte ab.

Welche Lösung ich für welches Projekt wählen würde

Wenn ich ein neues IoT-Setup bewerte, gehe ich ziemlich nüchtern vor. Für kleine bis mittlere Installationen mit begrenzter Hardware, klar umrissenem Standort und wenig administrativem Overhead würde ich Mosquitto nehmen. Als Faustregel passt das besonders gut, wenn du mit einigen hundert bis wenigen tausend Endpunkten arbeitest und die Betriebsanforderungen bewusst schlank hältst.

EMQX würde ich wählen, sobald mindestens einer dieser Punkte zutrifft: mehrere Standorte, Bedarf an Hochverfügbarkeit, ein Team, das Monitoring und Rollenverwaltung zentral braucht, oder ein Datenfluss, der nicht nur transportiert, sondern im Broker schon verarbeitet werden soll. Eine Rule Engine ist übrigens genau das: eine Schicht, die eingehende MQTT-Nachrichten filtern, anreichern oder umformen kann, bevor sie weitergeleitet werden. Das spart externe Zwischenstationen und macht das System oft übersichtlicher.

Für viele Projekte ist die beste Antwort aber kein Entweder-oder. Ich halte ein Hybridmodell oft für die intelligenteste Variante: Mosquitto am Rand, wo das Gerät nahe an der Anlage steht, und EMQX zentral, wo Daten zusammenlaufen, analysiert und an andere Systeme verteilt werden. Das passt besonders gut zu verteilten Infrastruktur- und Telekommunikationsaufgaben, bei denen lokale Robustheit und zentrale Sichtbarkeit zusammenkommen müssen.

Was ich vor dem produktiven Rollout prüfe

Bevor ich einen der beiden Broker live schalte, gehe ich eine kleine, aber harte Checkliste durch. Gerade weil beide Systeme einzeln gut dokumentiert sind, entstehen Fehler meist nicht am Broker selbst, sondern an den Annahmen rund um Last, Netz und Betrieb.

• Wie viele Verbindungen sind pro Standort realistisch, und wie stark schwankt die Last über den Tag?
• Welche Authentifizierung ist im Feld wirklich praktikabel: Zertifikate, Benutzer/Passwort oder JWT?
• Wie reagiert das System auf 5, 30 oder 120 Minuten Leitungsunterbrechung?
• Welche Topics, Payload-Größen und QoS-Stufen kommen im Alltag tatsächlich vor?
• Habe ich mindestens 30 Prozent Reserve bei CPU und RAM für Spitzenlast, Wartung und Wachstum?

Wenn ich den Vergleich auf einen Satz reduziere, dann so: Mosquitto ist der pragmatische Broker für schlanke, robuste Randknoten; EMQX ist die bessere Plattform, wenn Betrieb, Skalierung und Integration Teil des eigentlichen Produkts sind. Der sauberste nächste Schritt ist immer ein Test mit echten Topics, echten Payloads und echten Ausfällen, denn genau dort zeigt sich, welche Architektur im Alltag wirklich trägt.