MQTT vs. NATS: Das richtige Messaging-System für IoT wählen

Der Vergleich MQTT vs. NATS kommt auf, wenn ein Team die Einfachheit von NATS für Microservices schätzt und sich fragt, ob es damit auch seine Geräte bedienen kann. Beide sind schlanke Publish/Subscribe-Systeme mit Wildcard-Subscriptions und niedriger Latenz, wurden aber von sehr unterschiedlichen Clients geprägt. Dieser Leitfaden vergleicht Geräteunterstützung, Zustellgarantien, Persistenz und Ökosystem und erklärt, wo ein verwalteter MQTT-Broker neben NATS seinen Platz hat.

Zwei schlanke Pub/Sub-Systeme

MQTT ist ein offenes Standardprotokoll der OASIS. Jeder konforme Client kann mit jedem konformen Broker kommunizieren, und für beides gibt es zahlreiche Implementierungen. Es wurde für Telemetrie von ressourcenbeschränkten Geräten über unzuverlässige Netzwerke entwickelt, weshalb es Funktionen wie Last Will, Retained Messages und persistente Sessions mitbringt.

NATS ist ein Open-Source-Messaging-System und -Protokoll aus dem CNCF-Ökosystem mit einer primären Serverimplementierung. Es wurde für die Cloud-native Kommunikation zwischen Services gebaut: schnelles Request/Reply, Fan-out und lastverteilte Arbeitsverteilung innerhalb von Rechenzentren und über sie hinweg. Core NATS ist bewusst „Fire and Forget“; JetStream, im NATS-Server integriert, ergänzt Persistenz, Replay und stärkere Zustellgarantien.

Beide sind gut in dem, wofür sie entworfen wurden. Die Frage ist, welche Clients Sie verbinden.

MQTT vs. NATS auf einen Blick

Geräteunterstützung gibt den Ausschlag

Für IoT ist der praktischste Unterschied die Verfügbarkeit von Clients. MQTT-Clients gibt es für praktisch jede Plattform, mit der ein Geräteentwickler zu tun hat: ESP32- und Arduino-Bibliotheken wie PubSubClient, Embedded-C-Bibliotheken für RTOS-Ziele, Mobilfunkmodule mit MQTT in der Modem-Firmware, SPS und Industrie-Gateways mit integriertem MQTT sowie SCADA- und Historian-Software, die Sparkplug B spricht. Sensoren und Gateways von der Stange bieten MQTT oft als Konfigurationsoption an.

NATS-Clients sind hervorragend für Go, Rust, Java, .NET, JavaScript, Python und C auf Linux-fähiger Hardware. Ein Raspberry Pi oder ein Industrie-PC führt sie problemlos aus. Auf Mikrocontrollern und in Hersteller-Firmware ist NATS-Unterstützung selten. Wenn ein kommerzielles Gerät Daten senden soll, ohne dass Sie Firmware schreiben, spricht es fast sicher MQTT, nicht NATS.

Zustellgarantien und Persistenz

MQTT verankert Zustellgarantien in jeder einzelnen Nachricht. Ein Gerät kann über dieselbe Verbindung einen Alarm mit QoS 1 und einen hochfrequenten Vibrationsmesswert mit QoS 0 publizieren. Persistente Sessions halten QoS-1- und QoS-2-Nachrichten für einen getrennten Subscriber vor, und Retained Messages speichern den letzten Wert pro Topic, sodass ein später geöffnetes Dashboard sofort den aktuellen Zustand sieht. Details finden Sie unter MQTT-QoS-Stufen erklärt und MQTT Retained Messages.

Core NATS liefert an alle, die in diesem Moment verbunden sind, und an niemanden sonst. Das ist schnell und einfach und für viele Service-Aufrufe genau das richtige Modell. Brauchen Sie Dauerhaftigkeit, speichert JetStream Nachrichten in Streams mit Retention-Richtlinien, lässt Consumer bestätigen und erneut abspielen und kann anhand der Nachrichten-ID deduplizieren. JetStream ist für Historie und Replay leistungsfähiger als MQTT-Sessions, bringt aber eigene Konzepte mit (Streams, Consumer, Acknowledgment-Richtlinien), die jemand entwerfen und betreiben muss.

Präsenz und Gerätezustand

IoT-Systeme müssen ständig beantworten: „Ist dieses Gerät online, und was war sein letzter Messwert?“ MQTT beantwortet beides nativ. Ein Gerät setzt einen Last Will wie offline auf site1/pump7/status mit Retain-Flag, publiziert nach dem Verbinden online, und der Broker veröffentlicht den Will, wenn die Verbindung unsauber abbricht. Das vollständige Muster beschreibt der Leitfaden zu MQTT Last Will and Testament.

In NATS würden Sie Präsenz typischerweise mit Heartbeats jedes Geräts aufbauen oder Verbindungsereignisse aus dem System-Account des Servers beobachten und letzte Werte in einem JetStream-Key-Value-Bucket ablegen. Das funktioniert, aber Sie setzen es selbst zusammen, statt es nur zu konfigurieren.

Subjects vs. Topics

Die Namensmodelle sind sich ähnlich genug, um sie ineinander zu übersetzen. Ein MQTT-Topic factory1/line2/cnc1/temperature entspricht natürlich einem NATS-Subject factory1.line2.cnc1.temperature. MQTT + passt wie NATS * auf eine Ebene, und MQTT # passt wie NATS > auf den Rest. Für Industrie-4.0-Projekte ist das relevant, weil der UNS auf der MQTT-Seite liegt: Dort wird die ISA-95-Ausrüstungshierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und eine Bridge kann diesen Baum eins zu eins in Subjects wie acme.werk-stuttgart.montage.linie-1.zelle-3.temperatur spiegeln. Wie ein UNS aufgebaut ist, beschreibt der Leitfaden zu Sparkplug B und Unified Namespace. Der NATS-Server bietet sogar eine MQTT-Schnittstelle, die Topics auf diese Weise auf Subjects abbildet und MQTT-3.1.1-Clients annehmen kann – nützlich, wenn NATS bereits das Rückgrat bildet. MQTT-5-Funktionen unterstützt sie nicht; gleichen Sie die NATS-Dokumentation daher mit den Funktionen ab, auf die Ihre Geräte angewiesen sind.

Eine praxistaugliche Hybridarchitektur

Viele Teams nutzen beides, jeweils auf der passenden Schicht:

1. Geräte, SPS-Gateways und HMIs verbinden sich über TLS mit einem MQTT-Broker.
2. Ein Bridge-Service abonniert die Geräte-Topics und publiziert sie für Backend-Microservices erneut auf NATS-Subjects.
3. Services nutzen intern NATS-Request/Reply und Queue Groups und JetStream dort, wo sie dauerhafte Streams brauchen.
4. Befehle laufen zurück über die Bridge und werden auf dem MQTT-Befehls-Topic des Geräts publiziert.

Eine minimale Einweg-Bridge in Go sieht so aus, mit dem Eclipse-Paho-Go-Client und dem offiziellen NATS-Client.

package main

import (
	"crypto/tls"
	"log"
	"strings"

	mqtt "github.com/eclipse/paho.mqtt.golang"
	"github.com/nats-io/nats.go"
)

func main() {
	nc, err := nats.Connect(nats.DefaultURL)
	if err != nil {
		log.Fatal(err)
	}
	defer nc.Drain()

	opts := mqtt.NewClientOptions().
		AddBroker("tls://broker.connectmq.com:8883").
		SetClientID("YOUR_CLIENT_ID").
		SetUsername("YOUR_USERNAME").
		SetPassword("YOUR_PASSWORD").
		SetTLSConfig(&tls.Config{MinVersion: tls.VersionTLS12}).
		SetAutoReconnect(true)

	opts.SetOnConnectHandler(func(c mqtt.Client) {
		// Im Connect-Handler abonnieren, damit die Subscription nach Reconnects wiederhergestellt wird
		c.Subscribe("factory1/+/+/telemetry", 1, func(_ mqtt.Client, m mqtt.Message) {
			subject := strings.ReplaceAll(m.Topic(), "/", ".")
			if err := nc.Publish(subject, m.Payload()); err != nil {
				log.Printf("nats publish failed: %v", err)
			}
		})
	})

	client := mqtt.NewClient(opts)
	if token := client.Connect(); token.Wait() && token.Error() != nil {
		log.Fatal(token.Error())
	}
	log.Println("bridging MQTT to NATS")
	select {}
}

Der Paho-Go-Client verwendet MQTT 3.1.1, das ConnectMQ neben MQTT 5 akzeptiert. Zum Ausprobieren ohne Zugangsdaten nutzen Sie tcp://broker.connectmq.com:1883, eine beliebige eindeutige Client ID und ein Topic-Präfix wie connectmq/demo/<random-id>/ auf dem öffentlichen MQTT-Broker, der für Tests und nicht für Produktionsdaten gedacht ist. Achten Sie auf Zeichen, die in MQTT-Topics erlaubt, in NATS-Subjects aber Sonderzeichen sind, etwa . oder Leerzeichen, und bereinigen Sie sie in der Bridge.

Wann Sie was wählen

Wählen Sie MQTT, wenn Ihre Clients Geräte, Gateways, SPS oder Hardware von Drittanbietern sind, wenn die Konnektivität unzuverlässig ist oder wenn Sie Präsenz, gespeicherten Zustand und industrielle Konventionen wie Sparkplug B und einen UNS nach ISA-95 brauchen.

Wählen Sie NATS, wenn Ihre Clients selbst geschriebene Services in zuverlässigen Netzwerken sind und Sie schnelles Request/Reply, Queue Groups und optional JetStream-Persistenz bei minimaler Infrastruktur wollen.

Wählen Sie beides, wenn Sie eine Geräteflotte und ein Microservice-Backend haben, das bereits auf NATS standardisiert ist.

Für die Geräteschicht nimmt Ihnen ein verwalteter MQTT-Broker den Betrieb und die Absicherung eines aus dem Internet erreichbaren Dienstes ab. ConnectMQ bietet MQTT 3.1.1 und 5.0, TLS, Shared Subscriptions im kostenpflichtigen Serverless-Plan, Kontingente je Plan und Mandantenisolation – eine NATS-Bridge ist nicht integriert, die Bridge bleibt also wie gezeigt Ihr eigener kleiner Service. Wenn Sie auch andere Backends vergleichen, lesen Sie MQTT vs. Kafka, und für die Grundlagen das MQTT-Tutorial.

Starten Sie mit ConnectMQ

Geben Sie Ihren Geräten einen standardisierten, breit unterstützten MQTT-Endpunkt und behalten Sie NATS für Ihre Services. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, verbinden Sie ein Gerät und Ihre Bridge und beobachten Sie beide Seiten im Live-Topic-Explorer.

Häufig gestellte Fragen

Ist NATS schneller als MQTT?

Beide haben niedrige Latenz, und die Geschwindigkeit in der Praxis hängt stärker von Server, Netzwerk und Zustelleinstellungen ab als vom Protokoll. Entscheiden Sie nach Clients und Funktionen, nicht nach reiner Geschwindigkeit.

Können sich IoT-Geräte direkt mit NATS verbinden?

Linux-fähige Geräte können NATS-Clients verwenden. Mikrocontroller und kommerzielle Sensoren unterstützen NATS selten, weshalb MQTT auf der Geräteschicht dominiert.

Unterstützt NATS MQTT-Clients?

Der NATS-Server bietet eine MQTT-3.1.1-Schnittstelle, die auf JetStream basiert. MQTT-5-Funktionen deckt sie nicht ab, daher ist ein dedizierter MQTT-Broker für große, gemischte Flotten meist die bessere Wahl.

Was ist in NATS das Gegenstück zu einer MQTT Retained Message?

Am nächsten kommen ein JetStream-Stream, der so konfiguriert ist, dass er die letzte Nachricht pro Subject behält, oder ein JetStream-Key-Value-Bucket. Beides muss explizit eingerichtet werden.