NATS JetStream vs Kafka for Teams That Do Not Need Kafka's Scale

Every few months a team reaches for Kafka because it is the default answer to "we need a message log." Then they spend a sprint on partition counts, consumer group rebalancing, retention tuning, and wiring up an observability stack before a single business event flows through it. I have watched this happen on services that peak at a few thousand messages per second. That is not Kafka's home turf, and paying Kafka's operational tax to sit in it is a bad trade.

NATS JetStream is the persistence layer built into the NATS server. If you already speak the NATS subject model, you get durable streams, replayable history, and delivery guarantees by flipping one configuration flag. This post walks through streams, consumers, and the operational reality of running each, with a comparison table so you can make the call for your own workload.

What JetStream actually is

Core NATS is fire-and-forget pub/sub: if no subscriber is listening, the message is gone. JetStream adds a storage layer on top of the same server, so messages published to a subject are captured into a stream and can be replayed on demand. There is no separate process, no separate cluster, and no separate client library. You enable it with one flag and keep the same connection and subject model you already use.

# Enable JetStream in the server config file
# nats-server.conf
jetstream {
  store_dir: "/data/jetstream"
  max_memory_store: 1G
  max_file_store: 10G
}

# Or just a flag for local dev
nats-server -js

A stream defines what subjects it captures and how it retains data. The three retention policies matter because they map directly to common backend patterns.

• Limits — keep messages until an age, size, or count limit is hit. This is the Kafka-style replayable log.
• Work Queue — a message is deleted once a consumer acknowledges it. Perfect for job queues where each task runs exactly once.
• Interest — messages are kept only while there is an active consumer interested in the subject. A middle ground that avoids unbounded growth.

Consumers: push, pull, and acknowledgment

A consumer is a stateful view into a stream that tracks which messages a client has seen. Pull consumers are the modern default: the client asks for a batch when it is ready, which gives you natural backpressure and horizontal scaling without ever defining a partition. Multiple workers can share one pull consumer like a queue group, and the server load-balances across them.

Acknowledgment policy is where you tune delivery guarantees. Explicit ack means each message must be confirmed or it will be redelivered after a timeout — this is your at-least-once guarantee. JetStream also offers exactly-once using publisher message IDs for deduplication plus a double-ack on consumption. Contrast that with Kafka, where exactly-once requires transactions and idempotent producers configured correctly across the pipeline.

// TypeScript, using the nats.js client with JetStream
import { connect, AckPolicy } from "nats";

const nc = await connect({ servers: "localhost:4222" });
const jsm = await nc.jetstreamManager();

// Create a durable, file-backed stream
await jsm.streams.add({
  name: "ORDERS",
  subjects: ["orders.>"],
  retention: "limits",
  storage: "file",
  num_replicas: 3,
});

// Create a durable pull consumer with explicit ack
await jsm.consumers.add("ORDERS", {
  durable_name: "order-workers",
  ack_policy: AckPolicy.Explicit,
  max_deliver: 5,
  ack_wait: 30_000_000_000, // 30s in nanoseconds
});

const js = nc.jetstream();
const consumer = await js.consumers.get("ORDERS", "order-workers");
const messages = await consumer.consume({ max_messages: 100 });

for await (const m of messages) {
  await handleOrder(m.data);
  m.ack();
}

The operational reality

Kafka 4.0, released in March 2025, removed ZooKeeper entirely in favor of KRaft, its own Raft-based metadata layer. That is a genuine simplification — one system instead of two, and clusters that scale to millions of partitions. But KRaft does not remove the parts that actually cost you time: partition planning, consumer group rebalancing, retention and segment tuning, and understanding distributed log semantics before you can debug a lag spike.

JetStream ships as a single Go binary with no JVM to tune and no heap to size. On the VPS I run, a three-node clustered NATS deployment with JetStream enabled fits comfortably in memory that a single Kafka broker would consider an insult. Replication is Raft-based per stream, monitoring is a built-in HTTP endpoint, and the same nats CLI you use to publish also inspects streams and consumers. The whole thing is one mental model.

Head-to-head comparison

How I decide

1. Estimate real peak throughput. If it is under a few hundred thousand messages per second, JetStream is almost certainly enough.
2. Check your retention need. Days-to-weeks of replay is fine on JetStream file storage; months of petabyte-scale history leans Kafka.
3. Count your connectors. If you live in Kafka Connect and Schema Registry, staying in that ecosystem is worth more than shaving operational cost.
4. Weigh who operates it. A small team without a dedicated platform engineer will ship faster and sleep better on JetStream.

My rule is simple: reach for Kafka when you can name the specific Kafka feature you need — Connect, sustained massive throughput, or long compacted history. If your honest answer is "I need a durable, replayable message log with good delivery guarantees," JetStream gives you that with a fraction of the operational surface, and you can always graduate later if the load truly arrives.