Kafka 4.2 is KRaft-only, Pulsar 4.2 sharpens geo-replication, and NATS 2.12 pushes JetStream farther. Compare tradeoffs and fit. Read now.
KRaft-Only Kafka and What It Changes
Kafka 4.2 is KRaft-only. That ends the long dual path where cluster metadata lived in ZooKeeper while brokers handled the log. Metadata now lives in the same Raft-backed internal log model as the rest of the system, so operators reason about one consensus path instead of two. The practical upside is simpler deployment graphs, fewer moving parts in HA planning, and metadata operations that scale with the same operational habits you already use for partitions and replicas.
Architecturally, Kafka still centers on the partitioned, append-only log. Consumers pull, track offsets, and rebuild state by replaying. That model rewards high-throughput pipelines, long retention, and many independent consumer groups that need the same stream at different paces. The cost is partition planning: key design, rebalance behavior, and the fact that ordering is guaranteed only within a partition. If your workload is “durable bus with fan-out and replay,” Kafka’s fit remains the strongest of the three.
Pulsar’s Split Broker/Storage Model and Geo-Replication
Pulsar separates serving from durable storage. Brokers handle producers and consumers; a bookkeeper-style storage layer owns segments and replication. That split lets you scale write path and storage path independently, and it makes multi-tenant isolation (namespaces, quotas, auth boundaries) a first-class concern rather than an add-on. Topics can behave as queues or as streams depending on subscription type, which is useful when one platform must support both work-distribution and fan-out patterns.
Pulsar 4.2 sharpens geo-replication. Cross-region and multi-cluster setups are where Pulsar’s model tends to pay off: async or configured replication policies, topic-level placement, and clearer story for active-active or primary-secondary designs. The tradeoff is operational surface area. You run more roles, and debugging lag often means tracing both broker and storage health. Choose Pulsar when multi-tenancy, geo topology, and mixed queue/stream semantics matter more than a single-log mental model.
NATS, JetStream, and the Lightweight Path
NATS starts as a simple, subject-based messaging layer: publish, subscribe, request-reply, with low ceremony and small operational weight. NATS 2.12 pushes JetStream farther—the persistence and streaming layer on top of that core. JetStream adds durable streams, consumers with ack semantics, retention policies, and the ability to treat subjects as named, replayable logs without forcing a heavy cluster topology up front.
That combination fits edge, service mesh style internal events, and systems that need both fire-and-forget messaging and selective durability. You pay less in baseline complexity than Kafka or Pulsar, but you also inherit different scaling and retention assumptions. Very large, long-lived, multi-consumer analytics backbones still tend to land elsewhere. JetStream is strongest when you want messaging-first design with optional streams, not when the product is primarily a long-retention data bus.
How to Choose: Tradeoffs and Fit
- Kafka — Prefer for high-volume logs, many consumer groups, long replay windows, and teams already comfortable with partition-centric design. KRaft-only simplifies ops but does not remove the need for careful keying and capacity planning.
- Pulsar — Prefer when geo-replication, multi-tenant isolation, and independent scale of compute vs storage are central. Expect more components and richer topology controls.
- NATS + JetStream — Prefer for low-latency messaging with optional durability, simpler clusters, and request-reply plus streams in one stack. Validate retention and consumer semantics against your recovery requirements early.
Start from failure modes, not feature lists: who must not lose messages, how far back you replay, which regions must stay writable, and how many teams share the platform. Match those answers to log-first (Kafka), tenant-and-geo-first (Pulsar), or messaging-first with selective streams (NATS). Architecture fit is the constraint; version headlines only refine how each system is operated in 2026.