NATS vs MQTT: Which Messaging Protocol Should You Choose?

MQTT is the default answer for IoT messaging, and for good reason. It was designed for sensors on satellite links in the 1990s, and its three QoS levels, retained messages, and Last Will are purpose-built for unreliable networks and battery-powered devices. NATS comes from a different world: cloud-native microservices, request/reply, and extreme throughput on a single small binary.

The two overlap more than their histories suggest. NATS now ships persistence (JetStream), key-value and object stores, and even an MQTT compatibility layer, so "NATS vs MQTT" is no longer a clean either/or. This guide compares them on the decisions that actually matter: delivery guarantees, persistence, footprint, security, and where each fits in an industrial or backend architecture.

The Two Models in One Paragraph Each

MQTT is a publish/subscribe protocol with a central broker. Clients connect with a client ID, subscribe to topics with wildcards (sensors/+/temp), and publish messages that the broker fans out. QoS 0/1/2 trade delivery guarantees against overhead, retained messages store the last value on a topic, and Last Will publishes a message when a client dies ungracefully.

NATS is also publish/subscribe with a central (or clustered) server, but the core protocol is simpler: fire-and-forget at-most-once delivery, wildcard subjects, and request/reply built into the protocol itself. JetStream layers on persistence, replay, and acknowledgements when you need them. NATS also has a native MQTT adapter, so MQTT clients can publish and subscribe to a NATS server directly.

Delivery Guarantees: QoS vs At-Most-Once

This is the biggest conceptual gap, and it drives most architecture decisions.

Guarantee	MQTT	NATS Core	NATS JetStream
At-most-once	QoS 0	Default	n/a
At-least-once	QoS 1	n/a	Ack-based delivery
Exactly-once	QoS 2 (per-message)	n/a	Deduplication + acks
Persistence	None (broker memory)	None	JetStream streams

MQTT QoS 1 and 2 add round-trips: the broker acknowledges each publish, and QoS 2 runs a four-packet handshake to avoid duplicates. That is precisely what makes MQTT reliable on lossy links, and precisely why it carries more overhead per message than NATS core.

NATS core deliberately does not acknowledge publishes. If you need delivery guarantees, you enable JetStream and use streams + consumers, where the server persists messages and tracks consumer progress. The mental model shifts from "pick a QoS per publish" to "design a durable stream."

Persistence: Retained Messages vs JetStream

MQTT's retained message is a single cached value per topic. A new subscriber gets the last retained message immediately. It is great for "current temperature of device 7", but it cannot store history, replay, or recover missed messages.

JetStream is a full stream store. You define a stream bound to a subject, choose a retention policy (limits, interest, work-queue), and the server stores messages durably. Consumers then read with their own progress tracking, replay from the beginning, or pull only new messages. This is the gap MQTT users usually discover the hard way: QoS 1 gets a message to the broker, but if the subscriber is offline, that message is gone unless you run a bridge, a database, or an MQTT broker with persistence extensions.

If your requirement is "a sensor publishes every minute and we must not lose readings when the dashboard is down," JetStream's streams are the more natural fit. If the requirement is "show the latest value on reconnect," a retained message is enough.

Footprint and Operations

A stock MQTT broker (Mosquitto) is a small C binary that runs fine on an edge gateway. NATS is also a single small binary: the server itself ships as one executable with JetStream built in, no separate storage engine.

	Mosquitto (MQTT)	NATS Server
Runtime	Single binary (C)	Single binary (Go)
Persistence	None built-in	JetStream built-in
KV / Object store	Not included	Built on JetStream
MQTT clients	Yes	Via MQTT adapter
Request/reply	Not built-in	Core protocol feature

For a field fleet that is 100% MQTT sensors, a purpose-built MQTT broker is the simplest thing that works. For a system that also has backend services doing request/reply or needs a KV store, NATS collapses three pieces of infrastructure into one.

Security and Authentication

Both protocols support TLS and username/password authentication. NATS goes further with NKeys and JWT-based decentralized authentication: a key pair per user, signed by an operator account, which makes credential rotation and revocation practical at fleet scale. MQTT 5 added enhanced auth and more granular reason codes, but most MQTT deployments still authenticate with a username and password per device.

For industrial and edge deployments, the practical rule is the same for both: never expose the broker port to the public internet, put it behind TLS, and use per-device credentials with the least privilege your broker supports.

Which Should You Choose?

Use this as a rough decision map:

Choose MQTT if:

• Your devices are sensors, gateways, or PLCs that already speak MQTT with QoS expectations
• You need a broker small enough to run on an edge device next to the equipment
• Retained messages and Last Will cover your "latest value" and "device died" needs
• Your team and tooling are already MQTT-native (Node-RED, Grafana MQTT sources, etc.)

Choose NATS if:

• You need durable streams, replay, and per-consumer progress, not just last-value caching
• Your architecture includes microservices, request/reply, or a KV/object store
• You want one small server binary that does messaging, streaming, and KV
• You are building greenfield and prefer a cloud-native, cluster-friendly message bus

Run both if:

• Your field fleet is MQTT and your backend needs durable streams: NATS' MQTT adapter lets MQTT devices publish straight into JetStream subjects without a bridge.

Testing NATS Without the CLI

If you are evaluating NATS, the fastest way to get a feel for subjects, wildcards, JetStream, and KV is a GUI client rather than a terminal. NATS Explorer for macOS (also Windows and Linux) includes an embedded NATS server: one click and you have a local NATS + JetStream environment with a pub/sub panel, stream and consumer browser, and KV/Object store views. No Docker, no nats-server binary, no CLI.

Keep reading

Comparison NATS vs MQTT: Which Messaging Protocol Should You Choose? August 16, 2026 Guide NATS JetStream Explained: Streams, Consumers, and Durable Messaging August 16, 2026 Guide NATS Core vs JetStream vs KV Store: When to Use Each August 16, 2026