Skip to content

NATS

Cloud-native messaging — sub-millisecond pub/sub, request-reply, and JetStream persistence designed for microservices, edge, and IoT.

Overview

NATS is a simple, secure, high-performance messaging system designed for cloud-native applications, microservices, IoT, and edge deployments. Core NATS provides at-most-once pub/sub and request-reply with sub-microsecond latency. JetStream, NATS' persistence layer, adds at-least-once and exactly-once-by-sequence delivery, message retention, replay, Key-Value, and Object Store on top of a Raft-replicated log.

NATS' distinguishing trait is its decentralized JWT-based security model (operators → accounts → users) and its leaf-node + supercluster topology that lets a single logical fabric span data centers, public clouds, and edge devices with no overlay network.

Key Facts

Attribute Detail
Website nats.io
GitHub nats-io/nats-server
Stars ~16k+ ⭐
Latest Version v2.11.x (2026 line, see release notes)
Language Go
License Apache-2.0
CNCF Status Incubating (since 2018, originator: Synadia)
Commercial Synadia Cloud (managed multi-tenant + control-plane)
Single Binary Size ~22 MB (nats-server)

Evaluation

Pros Cons
Sub-microsecond latency for Core NATS in-cluster Subject-hierarchy design imposes vocabulary discipline
Single static binary, no runtime deps for Core JetStream R3/R5 quorum failure modes need study before relying on EOS
Per-account multi-tenancy with strict subject isolation Tooling (nsc) for decentralized auth has a learning curve
Leaf nodes + gateways for edge & multi-region Object Store and KV are convenience APIs over JetStream — same limits
30+ first-party client libraries (Go, Rust, Java, Python, .NET, JS, …) Not a drop-in Kafka replacement: no offset semantics, different consumer model
MQTT 3.1.1 / WebSocket / native support in one process Smaller ops community than Kafka or RabbitMQ
JetStream KV + Object Store eliminate need for Redis/MinIO in light cases Mirror/source streams need careful planning to avoid cycles

Architecture

flowchart TB
    subgraph ClusterA["NATS Cluster A (us-east)"]
        direction TB
        nA1["nats-server n1"]
        nA2["nats-server n2"]
        nA3["nats-server n3"]
        nA1 <--> nA2
        nA2 <--> nA3
        nA1 <--> nA3
    end
    subgraph ClusterB["NATS Cluster B (eu-west)"]
        direction TB
        nB1["nats-server n1"]
        nB2["nats-server n2"]
        nB3["nats-server n3"]
        nB1 <--> nB2
        nB2 <--> nB3
        nB1 <--> nB3
    end
    GW["Gateway link\n(supercluster)"]
    ClusterA <-.-> GW
    GW <-.-> ClusterB
    subgraph Edge["Edge / Factory"]
        Leaf["Leaf node"]
        Devices["IoT devices\n(MQTT/WS/NATS)"]
    end
    Leaf -- "leaf node link\n(account-scoped)" --> ClusterA
    Devices --> Leaf
    JS3["JetStream R3 stream"]
    nA1 -. "Raft group" .- JS3
    nA2 -. "Raft group" .- JS3
    nA3 -. "Raft group" .- JS3

See messaging/nats/architecture for component-level diagrams (cluster topology, JetStream replication, subject hierarchy).

Use Cases

  • Microservice request-reply — replace internal HTTP with sub-ms request-reply, queue-group load balancing across instances.
  • Edge / IoT fleets — leaf nodes at the edge with local Core NATS pub/sub, JetStream sync to central cluster.
  • Multi-tenant SaaS — per-tenant accounts give cryptographic subject isolation without per-tenant clusters.
  • Distributed state (KV) — JetStream KV bucket as a replicated map; replaces lightweight Consul/etcd use cases.
  • Object distribution (Object Store) — small/medium files (firmware, ML model snapshots) replicated through JetStream.
  • Cross-region async pipelines — gateways connect clusters with subject filtering for compliance boundaries.
  • MQTT bridge — accept MQTT 3.1.1 clients in the same process, route to NATS subjects.

Licensing & Pricing

  • NATS Server: Apache-2.0, free for any use.
  • nsc, nats CLI, nats-top, nack operator: Apache-2.0.
  • Synadia Cloud: commercial managed offering with global supercluster, identity, and observability. Per-connection / per-data billing.
  • Synadia Control Plane (NCP): self-hosted commercial control plane for managing fleets of NATS clusters.

License clarity

NATS itself has not adopted the BSL/SSPL relicensing pattern. The CNCF projects (server, CLI, NACK) remain Apache-2.0.

Ecosystem

Compatibility & Requirements

Requirement Detail
OS Linux, macOS, Windows, FreeBSD, ARM64 incl. Raspberry Pi
CPU x86_64, ARM64 (and 32-bit ARM for edge)
Storage (JetStream) local FS for store_dir — recommend NVMe; SAN OK for non-latency workloads
Network TCP 4222 (clients), 6222 (cluster routes), 7222 (gateways), 7422 (leaf nodes), 8222 (HTTP monitoring), 1883 (MQTT), 80/443 (WebSocket)
Memory 64 MB minimum for Core, JetStream sized to working-set
Container official nats Docker images, ~30 MB compressed

Latest Versions

  • Server 2.11.x — current 2026 stable line. JetStream consumer-name length increase, source/mirror improvements, MQTT v5 hardening.
  • Server 2.10.x — previous stable. Brought Pull-Consumer next-message API, subject delete tombstones, clustered KV watchers.
  • nats CLI v0.2.x — current 2026 line.
  • JetStream protocol revision: 1, with backward-compatible additions per release.

Track nats-server releases at github.com/nats-io/nats-server/releases.

Alternatives

  • Apache Kafka — log-structured stream, much larger ecosystem, much heavier ops; Kafka wins on replayable analytic streams.
  • RabbitMQ — AMQP broker with richer routing primitives (headers/topic exchanges), heavier per-message overhead.
  • Redpanda — Kafka-API compatible single-binary; competes more directly with Kafka than NATS.
  • Apache Pulsar — segregated compute/storage, multi-tenant, geo-replication; closer architectural match to NATS' multi-tenant model but heavier.
  • MQTT brokers (HiveMQ, EMQX, Mosquitto) — narrower scope, MQTT-only.
  • Redis Pub/Sub / Streams — embedded into Redis use cases; no replication-as-a-stream story.

Migration & Lock-in

  • Subject hierarchy lock-in — NATS' subject vocabulary (orders.created.us-east.123) tends to permeate code; migrating to Kafka topics is non-trivial.
  • JetStream is portable — exports/imports via nats stream backup / restore move data between clusters.
  • JWT auth lock-in — nsc-managed operators/accounts/users hash against NKeys; export creds first if migrating.
  • Mirror & source streams allow staged migration off a cluster without dual-write code.

Community Health

  • CNCF Incubating since 2018; well-maintained Synadia leadership.
  • Weekly community calls; active GitHub issues across nats-server, client repos, NACK, and NEX.
  • Regular release cadence (~quarterly minor versions).
  • Active commercial sponsor (Synadia) backing core development.

Sources

Open Questions

  • What is the practical ceiling for JetStream streams per cluster before metadata Raft contention bites? Synadia notes 100k+ streams are workable but reference architectures still cap at low tens of thousands.
  • How does gateway link bandwidth scale when many accounts have wide subject filters? Need a controlled measurement vs Kafka MirrorMaker 2 + Cluster Linking.
  • For Object Store, what is the largest single-object size before chunking overhead dominates throughput?
  • When mixing MQTT clients with native NATS clients on the same account, what is the impact on subject permission performance at >100k connections?
  • For EOS-by-sequence-number in JetStream, what failure modes can violate it (e.g. consumer state loss, manual purge, Raft leader-election windows)?