NATS: Technically Elegant, Clearly Limited Ceiling
Introduction
As someone developing a message queue, I keep an eye on various products in the industry. NATS is one that stands out—technically elegant with a clear design philosophy. But after studying it, I see a clear limitation: the ceiling is too low. It’s not that the tech is bad; the positioning constrains how far it can go.
This post shares my understanding of NATS’s architecture and why I think its ceiling is obvious. These are personal views, not a dismissal of NATS—just an analysis from a message queue practitioner’s perspective.
What Is NATS
NATS is an open-source messaging system created by Derek Collison, a veteran with 25+ years in messaging who worked on Cloud Foundry. NATS was initially developed at Apcera; Derek left in 2018 and founded Synadia to commercialize NATS. NATS is a CNCF incubating project under Apache 2.0.
NATS’s main traits are lightweight and high performance. It claims tens of millions of messages per second per node with microsecond latency. The NATS server is written in Go, a single binary with very simple deployment. The protocol is text-based with a small set of verbs, easy to understand and implement.
NATS positions itself as "connective technology" for communication between cloud, edge, and IoT devices. It supports pub/sub, request/reply, and queue groups. The design philosophy emphasizes simplicity, speed, and security over breadth and complexity.
Public users include Capital One, Mastercard, Ericsson, GE, Siemens, mainly for microservice communication, edge computing, and IoT data collection.
NATS’s Architecture
NATS uses a two-tier design: Core NATS and JetStream. The split is clear.
Core NATS is pure pub/sub with no persistence. Messages live in memory; they’re delivered if there are subscribers, otherwise dropped. This makes Core NATS very light: tens of millions of messages per second per node, microsecond latency, tens of MB of memory. The performance is impressive.
Core NATS offers at-most-once delivery—messages may be lost. That’s by design, not a flaw. By giving up persistence and stronger guarantees, it gains extreme performance and simplicity. For scenarios that don’t need persistence (real-time monitoring, heartbeats, ephemeral notifications), this tradeoff is reasonable.
JetStream is a later add-on persistence layer: message storage, replay, at-least-once and exactly-once guarantees. JetStream introduces Streams and Consumers and uses Raft for replication. This lets NATS serve scenarios that need persistence.
NATS’s subject-based addressing is clever. Messages are addressed by subject (string) with wildcard subscriptions. Publishers don’t need to know where subscribers are; the server routes automatically. Services can come and go, migrate, scale; clients don’t need config changes. This location transparency fits cloud-native well.
Deployment is minimal: a single binary, no external components (no ZooKeeper), little configuration. NATS can run anywhere—cloud, edge, even embedded. Compared to Kafka’s deployment, NATS has much lower friction.
Technically, NATS is well designed. Minimalism runs through the whole system; each choice has a clear reason. Performance numbers look good; docs and community are decent. As a technical product, NATS does well.
The Issues I See
But while studying NATS, some things puzzled me.
First, positioning. Core NATS is non-persistent, so it only fits "can lose messages" scenarios. Real-time monitoring, heartbeats, ephemeral notifications—these exist, but they’re a minority. Core internet use cases—orders, payments, user behavior, business events—cannot lose messages. Core NATS doesn’t fit those.
JetStream adds persistence, but then another question: if I need persistence, why not use Kafka directly? Kafka has more features, a larger ecosystem, more case studies. JetStream came late and lags Kafka in both features and ecosystem. As a user, what’s my motivation to switch to JetStream?
Second, protocol. NATS has its own protocol; it’s not compatible with Kafka or AMQP. That means high migration cost: rewrite clients, lose Kafka Connect’s hundreds of connectors, switch monitoring tools, relearn operations. That’s a lot. Unless NATS has overwhelming advantages, users won’t switch.
Third, market size. In years in internet and cloud, I rarely hear NATS mentioned. When people discuss message queues, it’s Kafka, RabbitMQ, Pulsar. NATS is hardly on the radar.
From public user cases, NATS is mainly in financial internal messaging, industrial data collection, telecom signaling—relatively niche. Typical internet companies (e-commerce, social, search) rarely use NATS. So NATS serves a niche, not the mainstream. Even in high-performance use cases, the mainstream choice is still tuning Kafka or using Redpanda, not switching to NATS.
Fourth, Go’s limits. NATS server is in Go; GC can become a bottleneck under load. From GitHub issues, NATS has had memory issues; JetStream has had abnormal memory growth in some scenarios. These may be specific cases, but they suggest Go’s memory management is less controllable than Rust or C++. For a messaging system chasing extreme performance, language limits will show.
Where the Ceiling Is
Putting this together, I think: NATS’s ceiling is set by its positioning.
NATS chose the niche of "lightweight real-time communication without persistence." That market exists but is small. The message queue market itself isn’t huge; NATS picked an even smaller segment. Even with 100% share in that segment, the scale is limited.
That explains why Synadia (NATS’s company) has stayed small for years. Not because they do poorly—Derek Collison is a strong technical leader. But the niche is narrow; it’s hard to grow much. Confluent (Kafka’s company) serves the mainstream market and has grown to thousands of people and billions in valuation.
JetStream, added later, effectively acknowledges "the pure-memory market is too small." But by then Kafka and Pulsar were mature. JetStream still lags Kafka in features and ecosystem. For users needing persistent stream processing, Kafka remains the first choice.
Protocol incompatibility further limits adoption. Ecosystem migration cost is high; most companies won’t take that risk. Even if NATS is better in some ways, "a bit better" doesn’t outweigh migration cost. Unless it’s a greenfield project, choosing NATS is hard.
My Take
NATS will continue to exist and serve its niche, but I don’t see a major breakthrough. Market size caps growth; that’s not something technology alone can change.
For me, NATS is more of a cautionary tale. It shows: positioning matters more than technology. Elegant tech can’t compensate for the wrong market. Simplicity and high performance have a cost—giving up persistence limits use cases. New protocols incur high ecosystem cost; incompatibility with mainstream protocols hinders adoption.
When developing RobustMQ, I often think of NATS. It reminds me not to be seduced by elegant tech and go down a niche path. The mainstream needs of message queues are persistence, reliable delivery, and data pipelines—that’s Kafka’s market and should be RobustMQ’s target too.
NATS’s architecture is worth studying: subject-based addressing, location transparency, single-binary deployment. But these should be built on top of "persistence + full features + ecosystem compatibility," not traded away for minimalism.
Summary
NATS is a technically elegant product with clear market limits. Its architecture pursues simplicity and performance and achieves both technically. But positioning constrains its growth.
Lightweight real-time messaging is a niche; the market is small. A new protocol isolates the ecosystem and raises migration cost. Go imposes performance limits. Together, these define NATS’s ceiling.
NATS will have its niche and serve specific users, but it won’t become mainstream. That’s not an execution problem; it’s a strategy problem. Great technology doesn’t change the ceiling if the market is wrong.
As a message queue practitioner, I appreciate NATS’s technical design but wouldn’t choose its market path. Infrastructure software’s value lies not only in technical elegance but in addressing mainstream needs, building a complete ecosystem, and serving a large enough market. That’s the main lesson NATS offers.