NATS vs Kafka: Core NATS, JetStream and Kafka Compared

Core NATS is fire-and-forget messaging. A publisher sends to a subject such as orders.eu.created; every subscriber whose subject or wildcard matches at that moment gets a copy; anyone offline misses it. The NATS documentation describes this as at-most-once delivery that is never replayed. On top of that sit request-reply and queue groups, which spread messages across a pool of subscribers for load balancing. There is no broker-side storage to size and nothing to clean up, which is why Core NATS is often used for service-to-service calls, control-plane traffic and telemetry where the latest value matters more than every value.

JetStream is the persistence layer built into the same server. A stream captures every message published to its subjects and gives each a sequence number. Consumers are server-side cursors over a stream: the server tracks how far each one has read, redelivers anything not acknowledged in time, and several consumers can read the same stream independently. That makes JetStream the part of NATS that actually competes with Kafka.

Kafka and JetStream both default to at-least-once delivery, so both can produce duplicates after a retry or a consumer restart. They handle it differently. Kafka's idempotent producer removes duplicates caused by producer retries, and transactions let a stream processor commit consumed offsets and produced records atomically, which is how Kafka Streams gets exactly-once processing between topics.

JetStream deduplicates on the way in: a publisher sets a Nats-Msg-Id header, and the stream rejects a second message with the same ID inside its duplicate window, two minutes by default. On the way out, the application still needs idempotent processing, as it does with any at-least-once consumer. If your design depends on atomic read-process-write across several streams of events, Kafka's transactional model is the more established option.

Kafka keeps records until a retention limit removes them, seven days by default, or keeps the latest value per key forever with log compaction. Reading never deletes anything, so a new consumer group can replay months of history. That is the property that makes Kafka a system of record for event sourcing and change data capture.

JetStream offers three retention policies. Limits keeps messages until a size, age or count limit is reached, which behaves like a Kafka topic. Interest deletes a message once every consumer has acknowledged it. WorkQueue deletes it after a single acknowledgement, which turns the stream into a durable queue. JetStream can also cap messages per subject, which is useful for keeping the last state of each device or entity. Replay works from the beginning, a sequence number or a point in time, within whatever the retention policy kept.

Kafka scales a topic by splitting it into partitions spread across brokers. Ordering holds within a partition, the record key chooses the partition, and a consumer group assigns each partition to one member, so the partition count caps consumer parallelism. Choosing it is a design decision covered in our Kafka architecture guide.

NATS addresses data by subject, a dot-separated hierarchy with wildcards, so consumers filter by meaning (orders.*.created) rather than by partition number. A JetStream stream has one leader that takes every write, so a single stream's throughput is bounded by one server. Large deployments spread load across several streams, or use subject mapping to split one subject space into deterministic partitions. NATS gives more flexible routing; Kafka gives more predictable horizontal scaling of a single high-volume topic.

Since Apache Kafka 4.0, released on 18 March 2025, ZooKeeper is gone and KRaft controllers, a Raft-based quorum, manage cluster metadata. Partitions are replicated across brokers, usually three times. Running Kafka well means sizing brokers and disks, managing partition counts and rebalances, and operating Connect and schema tooling alongside it.

A NATS server is a single small binary. Servers form full-mesh clusters, clusters join into superclusters through gateways, and leaf nodes extend the system to edge sites. JetStream uses Raft too: a meta group places streams and consumers, and each stream and each consumer gets its own Raft group, with at most five replicas per stream. The documentation recommends an odd number of servers, typically three or five, so a majority can always form.

Kafka's ecosystem is the larger one: Kafka Connect with a large catalog of source and sink connectors, Kafka Streams for stateful processing, Debezium for change data capture, schema registries, and a wire protocol also spoken by Amazon MSK, Confluent Cloud, Azure Event Hubs and Redpanda. Kafka 4.2 made share groups production-ready, adding queue-style consumption on ordinary topics.

NATS bundles more into the server instead: a key-value store and an object store, both built on JetStream streams, plus MQTT and WebSocket support and clients in most languages. Both projects are Apache 2.0. Kafka is governed by the Apache Software Foundation. NATS has been a CNCF incubating project since 15 March 2018; after a public dispute in 2025 over Synadia's plan to move the server to a Business Source License, CNCF and Synadia agreed on 1 May 2025 that NATS stays in CNCF under Apache 2.0, with Synadia transferring the NATS trademarks.

1. Must new consumers replay weeks or months of history, or must data be compacted by key? Kafka.
2. Do you need exactly-once read-process-write between topics, or Kafka Connect and Debezium? Kafka.
3. Is the main need low-latency request-reply, fan-out to services and devices, or links to edge sites? NATS, with Core NATS for transient traffic.
4. Do you want durable queues, a key-value store and messaging from one lightweight server? NATS with JetStream.

Moving between them is an application change, not a configuration change: the client APIs, delivery model and addressing differ. Bridging is common, with a connector or small service copying selected NATS subjects into Kafka topics for long-term retention.