Beyond StreamingLog Processing
NATS JetStream and Apache Kafka — the architectural differences that matter, and where each one wins.
Executive Summary
NATS JetStream and Apache Kafka overlap in functionality but differ in architecture.
Apache Kafka is a distributed append-only log processing system designed for write throughput; at its core, log persistence and replay is its sole function. That core publish/consume functionality is limited, which is why the Confluent Platform adds further components — each a separate JVM process — to offer a more complete set. If you want to do things such as:
- Filtering of messages in topics
- Merging topics into other topics
- Using streams as Key/Value tables or as queues
…then you also need Kafka Streams, Flink, MirrorMaker and others. That means running many more JVMs than just the Kafka brokers (and ZooKeepers, if you haven't migrated to version 4), and some of the data is constantly shuffled back and forth between the broker and the Kafka Streams JVMs, and may end up stored several times over across several topics — affecting latency, efficiency and resource usage, and, on cloud services, adding noticeably to networking and storage costs.
NATS consolidates messaging, streaming, Key/Value, Object Store, queue semantics, service discovery, multi-region super-clustering, edge leaf nodes, MQTT and WebSockets into a single binary with a single operational surface — under 20MB, with zero dependencies. The practical consequences of that architectural difference show up across every dimension compared in this paper.
Kafka 4 has closed some historical gaps, but the architectural difference remains: Kafka's model is a partitioned append-only log extended by external components, while NATS JetStream is a consistent addressable message store with messaging, queuing and data storage built in.
Neither system is universally better. Kafka's ecosystem depth, transactional model and throughput optimisations make it the stronger choice for large-scale log processing with deep Flink, Iceberg and Schema Registry integration. NATS JetStream's unified architecture, operational simplicity, compliance-friendly deletion, multi-tenant security and edge deployment make it the stronger choice for teams building distributed applications that span messaging, streaming and data storage on one platform.
The two are not mutually exclusive — they bridge cleanly via Synadia Connect, Debezium Server, or direct protocol adapters, and can coexist cooperatively in the same architecture.
01
The bottom line
Key Takeaways
NATS with JetStream persistence is not merely a lighter-weight Kafka alternative but a fundamentally different architecture — one that collapses the distinction between messaging, streaming, queuing and data storage into a single system, a single binary and a single operational surface.
The differences that matter most fall into five categories.
Architecture
Kafka separates concerns across brokers, controllers, Connect workers, Schema Registry, stream processing runtimes and replication tools — each adding operational surface. NATS consolidates messaging, streaming, Key/Value, Object Store, queue semantics, super-clusters, leaf nodes, WebSockets, MQTT, service discovery and stream mirroring into a single nats-server binary. Features are enabled in configuration, not by deploying new infrastructure.
Addressing and storage
Kafka stores data in partitioned, append-only topic logs addressed by offset. JetStream stores data in streams addressed by hierarchical subjects with wildcards, supports individual message deletion, can enforce per-subject constraints, and exposes atomic compare-and-set write control — making it simultaneously a stream, a key/value store, an object store and a durable work queue. Targeted deletion for GDPR becomes a single API call rather than an architectural workaround.
Consumption
Kafka ties consumer parallelism to partition count and — even with share groups — retains partitions as a foundational abstraction. JetStream consumers are partition-less by default: scaling up or down is a client-side operation with no server-side rebalance. Where subject-based partitioning is genuinely needed, the Orbit client extensions provide it as an opt-in layer rather than a mandatory constraint.
Multi-tenancy, security, and deployment
NATS provides account-level multi-tenancy with isolated subject namespaces, delegated administration via JWTs and scoped signing keys, and a security callout for external identity providers. Topologies span single clusters, super-clusters across regions and clouds, and leaf nodes at the edge with store-and-forward resilience. Kafka has no native equivalent to accounts, super-clusters or leaf nodes.
Observability
NATS embeds monitoring in the server process: JSON telemetry endpoints, a push-based system account event channel, and — since 2.11 — built-in distributed message tracing from a single CLI command. Kafka's observability depends on JMX, external exporters and client-side OpenTelemetry instrumentation, with no server-side message tracing.
Where Kafka is stronger
Read this before assuming a migration
- Kafka is proven for extremely high-throughput append-only workloads: batched ISR replication is optimised for maximum write throughput on large partitioned topics, while JetStream's per-message Raft consensus gives stronger consistency guarantees at a throughput cost that can matter at the very highest end with small messages, where you end up partitioning over multiple streams to scale.
- Kafka’s deep ecosystem and tight integration with Apache Flink, Iceberg and the broader lakehouse are genuine strengths. The NATS ecosystem is growing — Synadia Connect, Debezium Server with the JetStream sink, Flink connectors — but it is smaller.
JetStream is the better fit — often decisively — for the workloads below.
- Low latency
- NATS is designed for low latency rather than batching and compression for throughput; Kafka is the other way around.
- Unified messaging and streaming
- Workloads needing both low-latency request/reply and durable streaming in one system, without operating two separate platforms.
- Multi-tenant SaaS platforms
- Account-level isolation with delegated security administration, independent subject namespaces and per-account resource limits — without manually carving up a topic namespace.
- Edge, IoT, and intermittent connectivity
- Leaf nodes with local JetStream domains give always-on messaging and store-and-forward durability even when disconnected from the hub, syncing automatically on reconnect. Native MQTT support removes the need for a protocol bridge.
- Compliance-sensitive workloads
- Any pipeline carrying personal data subject to erasure requests benefits from JetStream's per-message and per-subject deletion, secure overwrite and audit trail.
- Operational simplicity
- Teams that want a streaming platform they can deploy, operate and monitor without JVM tuning, partition planning, multi-component coordination, or assembling an observability stack from parts.
- Global and multi-cloud deployments
- Super-clusters with transparent cross-cluster routing, geo-affinity for request/reply, and built-in stream mirroring and sourcing — without MirrorMaker, Cluster Linking or third-party replicators.
NATS and Kafka also coexist well. Synadia Connect can bridge the two, consuming from Kafka topics and producing to JetStream streams or the reverse, with transformation and filtering in the pipeline. Debezium Server can feed CDC events from the same databases into both systems independently. Organisations migrating incrementally can run both side by side, moving workloads as confidence grows, without a hard cutover.
The question is not which system is universally better — it is which architecture fits the workload better.
For distributed log processing at massive scale with a deep surrounding ecosystem, Kafka is proven. For a unified messaging, streaming and data store platform that is simpler to deploy, operate and extend to the edge, NATS JetStream offers capabilities Kafka's architecture cannot replicate without significant additional infrastructure.
02
The full paper
What's Covered in Detail
The complete paper goes deep on every topic below — architecture, semantics, operations, and the practical consequences of each design choice.
- 01
Introduction
Executive Summary
- 02
Components
Runtime and footprint · Processes · A note on the broader ecosystem
- 03
Functionality
“Messaging” vs “streaming” · Messages · “Subjects” vs “topics” · Streaming functionality · Qualities of service · JetStream persistence beyond streams · Queuing · Cross-cluster behaviour · Microservices vs CQRS · Durability
- 04
Protocol
Wire protocol and client behaviour
- 05
Security
Authentication · Multi-tenancy · Encryption · Message deletion, data compliance and GDPR · Layer 7 firewalling
- 06
Deployment and operations
Resilience · Clustering · Super-clusters and leaf nodes · Data placement
- 07
Operations
Container orchestration · Observability and monitoring · Distributed message tracing
- 08
Administration
Admin UI
- 09
Change data capture
What NATS adds to CDC · Other CDC tools
- 10
Stream processing and platform
The three tiers of the Kafka-side compute layer · Why the NATS-side layer is thinner by design · Direct client implementation · Synadia Platform · Flink with NATS · KStreams and KTables against JetStream primitives
- 11
Summary
They are not mutually exclusive · Learn more
03
The full argument
Get the Complete White Paper
The summary above is the argument in outline. The paper itself works through every dimension chapter by chapter, with configuration examples and the full side-by-side comparison.
Inside the paper
- A component-by-component comparison of both runtimes, from binary footprint to the JVM processes a production Kafka deployment still needs
- How subjects and wildcards differ from partitions and offsets, and what that changes about consumer parallelism
- Message deletion, secure overwrite and audit trails — and why GDPR erasure is an API call rather than a workaround
- Multi-tenancy compared: NATS accounts and scoped signing keys against Kafka ACLs
- Super-clusters, leaf nodes and data placement, against MirrorMaker and Cluster Linking
- Where each system genuinely wins, and how to bridge the two with Synadia Connect or Debezium Server
- Author
- Jean-Noël Moyne
- Version
- V 2.0, 2026
- Format
One operational surface
Messaging, streaming, Key/Value, Object Store and queues in a sub-20MB binary with zero dependencies.
Compliance by design
Per-message and per-subject deletion with secure overwrite, rather than a retention-window workaround.
Edge as a topology
Leaf nodes with local JetStream domains keep working while disconnected, then resync on their own.
04
Common questions
