NATS

What it is

NATS is a messaging system built for connective tunnels between distributed systems — services, devices, edge nodes, cloud regions, whatever needs to talk to whatever else. Core NATS gives you pub/sub, request/reply, and queue groups over a lightweight text protocol. JetStream, its persistence layer, adds streaming, at-least-once/exactly-once delivery, and message replay on top of that core. The pitch is simplicity: a single small binary, sub-millisecond latency, and a security model (accounts, multi-tenancy) that doesn't require bolting on a separate auth system. It competes in the same conceptual space as Kafka and RabbitMQ but takes a different bet — fewer moving parts, easier ops, and a topology that can reconfigure itself (clustering, leaf nodes, superclusters) without downtime.

Who builds it and why

NATS originated at Apcera and has been stewarded by Synadia since the company split off to focus on it commercially. It's a CNCF incubating project, which means it's past the "toy project" stage but not yet at the graduated tier of things like etcd or containerd. 230 contributors and a steady commit cadence (latest release v2.14.3, commits as recent as mid-2026) indicate active maintenance, not abandonware. Synadia runs a hosted NATS offering and sells support, which is the usual open-core-adjacent model for CNCF infra projects — the community gets a genuinely open Apache-2.0 codebase, the company monetizes the operational layer.

Production readiness signal

20K GitHub stars is respectable but not enormous for a messaging system this old — Kafka and RabbitMQ both dwarf it in ecosystem size and Stack Overflow answers. That's a real signal: fewer people have hit your specific edge case before you. That said, NATS has been running in production at companies like Cisco, Baidu, and Tesla-adjacent IoT workloads for years, and it's a CNCF project with real governance, not a single-maintainer side project. JetStream is younger than core NATS and has had rough edges in early versions around clustering and storage recovery — check the changelog for your target version before committing to it for anything durability-critical. If you need core pub/sub only, core NATS is battle-tested and boring in the good way.

Who should use this

• Teams building IoT/edge architectures where NATS's small footprint and leaf-node topology genuinely fit better than a JVM-based broker
• SaaS platforms that need real multi-tenancy (NATS accounts) without building isolation logic themselves
• Go shops that want a messaging layer written in the same language as their services, with minimal operational surface area
• Anyone who wants request/reply semantics as a first-class primitive, not bolted onto a pub/sub model

Who should NOT use this

• Teams that need Kafka's ecosystem — Kafka Connect, ksqlDB, the enormous library of connectors and tooling. NATS's ecosystem is much thinner.
• Organizations with existing deep Kafka or RabbitMQ investment and no specific pain point NATS solves. Don't migrate for novelty.
• Anyone needing long-term, high-volume event log retention with heavy analytics workloads on top — JetStream can do storage, but it's not built to be a data lake substitute.
• Teams that need a large hiring pool of engineers who already know the tool. NATS expertise is scarcer than Kafka or RabbitMQ expertise in most job markets.

Alternatives

• Apache Kafka — the default choice for high-throughput event streaming with a massive ecosystem; heavier to operate.
• RabbitMQ — more mature broker-style messaging with strong routing flexibility; less suited to edge/IoT topologies.
• Redis Streams / Pub/Sub — lighter-weight option if you already run Redis and don't need NATS's multi-tenancy or clustering model.

Pricing

NATS core and JetStream are fully open source under Apache-2.0 — no license fees, no feature gating. Synadia sells a hosted cloud version and enterprise support contracts, but nothing in the core project is paywalled.