NATS gains ground as teams rethink RabbitMQ

Software teams building cloud-native, edge and AI-driven systems are increasingly evaluating NATS as an alternative to RabbitMQ, drawn by lower-latency messaging, simpler deployment and a communication model designed around distributed services rather than conventional broker-centric queues.

The shift has gained fresh attention with NATS Server 2.15, released on September 17, which concentrates on reliability and operations. Its maintainers reworked stream and consumer scaling, movement and peer changes, improved backups and source recovery, and reported substantial performance gains for replicated JetStream streams configured to synchronise every message to disk.

NATS said tests on three AWS instances showed about 10 per cent higher throughput under normal replicated-stream settings. With the stricter “sync: always” setting, throughput rose from hundreds of messages a second to tens of thousands while tail latency fell by more than 40 per cent. Those figures are vendor benchmarks and may not translate directly to every production workload.

The release reinforces a broader architectural argument behind NATS adoption. Core NATS uses lightweight subject-based publish-and-subscribe messaging and request-reply communication, while JetStream adds persistence, durable consumers, replay, work queues and replicated storage. This lets developers use one system for ephemeral service communication and durable messaging rather than introduce separate infrastructure for each pattern.

AI applications are adding another use case. Multi-agent systems often require many autonomous components to exchange state, tasks and events in real time, with participants appearing and disappearing dynamically. NATS contributors have highlighted subject-based routing, request-reply and JetStream persistence as useful building blocks for such systems, particularly where agents must communicate laterally instead of through a single central controller.

Evidence of migration exists, though claims of a mass abandonment of RabbitMQ are difficult to verify. Sophotech, a technology consultancy, has described moving about 50 microservices from RabbitMQ to NATS. The company said its p99 messaging latency fell from roughly 150 milliseconds to about 40 milliseconds, operational work dropped from several hours a week to less than one, and burst-related queue delays were reduced from minutes to seconds.

Those results illustrate why NATS can appeal to teams running large numbers of services in Kubernetes or across regions. Its server is distributed as a single binary, subjects replace many exchange-and-queue routing constructs, and leaf nodes can link edge locations with larger clusters. That can reduce configuration and operational complexity when applications primarily need fast service-to-service communication, event distribution or geographically dispersed messaging.

RabbitMQ, however, remains actively developed and continues to address many of the same modern requirements. Version 4.3, released in April and updated to 4.3.6 on September 16, expanded quorum queues with strict message priorities, delayed retries and consumer timeouts, while improving AMQP 1.0 support. RabbitMQ also offers streams and super streams for persistent, replicated, high-throughput workloads.

Its quorum queues use the Raft consensus algorithm and are intended for workloads where message safety and predictable failover matter more than minimum latency. RabbitMQ documentation recommends quorum queues as the default replicated queue type, while streams provide repeatable consumption and append-only storage for fan-out and high-throughput applications.

That difference matters because replacing RabbitMQ is not automatically an upgrade. Enterprises that depend on mature AMQP semantics, complex routing, message priorities, broad protocol support, established operational tooling or long-lived transactional workflows may find little benefit in moving. RabbitMQ also supports MQTT and STOMP alongside AMQP, features that can be important in heterogeneous environments.

NATS has narrowed an earlier functional gap through JetStream. The persistence layer supports durable streams, consumers and replay while retaining NATS subjects as the addressing model. That combination allows teams to start with transient messaging and add storage selectively, rather than making durability a requirement for every exchange between services from the outset.