To benchmark NATS against Kafka today, compare NATS JetStream with Apache Kafka—not the deprecated NATS Streaming Server (STAN). There is no meaningful universal winner on throughput: results depend on workload, durability settings, hardware, and topology. A useful comparison measures performance and recovery under the same requirements, then weighs those results against each system’s data model and operational fit.
What “NATS Streaming” means today
NATS Streaming (STAN) is a legacy product, not the current NATS persistence option. NATS’s legacy documentation says the NATS Streaming Server was being deprecated and that critical bug and security fixes would continue until June 2023; it directs applications needing persistence to JetStream. NATS’s JetStream concepts documentation says JetStream “completely replaces the STAN legacy NATS streaming layer.” For a current Kafka alternative comparison, benchmark JetStream and Kafka. A historical STAN benchmark does not establish how current JetStream performs.
What the benchmark is comparing
Apache Kafka describes itself as an event-streaming platform that combines publishing and subscribing, durable storage, stream processing, and routing events to destinations. Kafka stores events in topics divided into partitions across brokers. A record’s key can determine its partition, and order is guaranteed within a topic-partition. Replication can protect topics against broker failure.
JetStream is the NATS persistence layer. Streams store messages; consumers track delivery and acknowledgments. JetStream supports durable consumers, replay, replication, retention policies, and at-least-once delivery. These are not identical architectures, so the test should compare the systems against the same application requirements rather than assume that a topic and partition map one-to-one to a stream and consumer.
#1 Best Overall
Choose the workload before choosing a winner
“NATS throughput” and “Kafka throughput” are incomplete claims without a workload definition. Decide what the application must do, then configure both systems to provide equivalent behavior. Record these details with every result:
- Software and machines: broker and client versions, operating system and kernel, CPU, memory, storage device and filesystem.
- Topology: number of brokers, network layout, replication factor, Kafka partition count, and JetStream stream and subject layout.
- Messages: payload size and format, serialization, producer count, consumer count, and whether traffic is uniform or keyed.
- Write behavior: batching, compression, acknowledgment settings, and durability requirements.
- Retention: the configured retention policy and age, byte, or message-count limits, where applicable.
- Failure conditions: which broker or network failures are injected, when they occur, and how recovery is measured.
Do not compare Kafka with three replicas and synchronous durability against an in-memory JetStream test, or compare unlike retention and acknowledgment settings. Such a result primarily measures configuration choices, not an inherent product advantage.
Rank #2
Measure more than peak throughput
Run separate tests for distinct operating conditions. A single maximum messages-per-second figure hides latency, replay, and failure behavior that may matter more to a production service.
| Test | What to record | Why it matters |
|---|---|---|
| Peak throughput | Sustained messages or bytes per second at the stated payload size and settings | Shows the highest rate the tested configuration handled; it is not a general product limit. |
| Steady-state throughput | Throughput over a representative interval, with resource use and latency | Reveals whether a short burst can be sustained without growing queues or degraded service. |
| Latency | Median and p95/p99 end-to-end latency, measured under stated load | Exposes the experience of typical and slower operations, not just the average. |
| Replay and catch-up | Time to replay a defined backlog and return a lagging consumer to current traffic | Tests retrospective reads and recovery from a consumer falling behind. |
| Broker failure and recovery | Write availability, interruption duration, data integrity, and time to resume normal operation | Tests the configured replication and recovery behavior rather than only healthy-cluster speed. |
| Consumer lag | Lag growth and drain rate while producers continue publishing | Shows whether consumers can keep up and how the system behaves when they cannot. |
Run each test repeatedly under the same conditions and publish the methodology, not just the best run. State whether the reported rate is messages or bytes per second, include the payload size, and identify whether latency is measured at the producer, broker, or consumer boundary.
Rank #3
Account for retention, replay, and delivery semantics
Kafka: replay from retained topic data
Kafka does not remove a record simply because a consumer has read it. Topic retention policy determines when retained events are discarded, so consumers can read the data repeatedly while it remains available. Test replay by defining the retained window and backlog, then measuring how quickly consumers can reprocess it while new events arrive.
JetStream: stream storage and consumer state
JetStream separates stored stream messages from consumer delivery state. Its retention choices include limits-based, work-queue, and interest-based policies, with age, byte, and message-count limits. Consumers can acknowledge messages; unacknowledged messages may be redelivered, which is part of at-least-once delivery behavior. Specify the chosen policy and acknowledgment configuration in a benchmark because they affect both what remains available and the work the system performs.
For either platform, test the retention and replay behavior the application actually needs. A benchmark with a short retention window cannot support a conclusion about long-term replay requirements.
Interpret scaling and ordering in the architecture’s terms
Kafka’s partition count defines a central part of its parallelism and ordering scope: records in one topic-partition are read in write order, while a topic’s work is spread across its partitions. Consumer parallelism and ordering requirements therefore need to be considered together when choosing partition layout.
Best Value
JetStream’s streams and consumers configure persistence, acknowledgment, replay, and retention. Benchmark the subject layout and consumer behavior your application will use rather than treating a NATS subject as equivalent to a Kafka partition. Report the layout alongside throughput so readers can understand what was parallelized and what ordering guarantee the test preserved.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use vendor benchmarks cautiously
Synadia has published a NATS–Kafka report comparing throughput and total cost of ownership. It is vendor-published evidence, not a neutral independent result. Do not repeat a numeric claim without examining the report’s workload, software versions, infrastructure, durability and retention settings, and failure procedure. No neutral, current, independently reproducible cross-platform benchmark is established in the sources for this comparison, so there is no supported universal throughput figure to report.
Choose by requirements, not a headline number
| Requirement | Architecture-based fit | Benchmark or design question |
|---|---|---|
| Partitioned durable logs and long-lived replay | Kafka is a natural fit when durable, replayable partitioned logs and long retention are central requirements. | Can the chosen partition layout meet throughput and ordering needs while retaining data for the required period? |
| Broad connector ecosystem | Kafka is a natural fit when broad connector availability is central to the integration plan. | Are the required source and destination connectors available and suitable for the deployment? |
| NATS request/reply alongside persistence | JetStream is a natural fit when a NATS-based system needs integrated persistence alongside request/reply messaging. | Can one NATS-based platform satisfy the streaming workload, retention, and recovery requirements? |
| Flexible stream retention and durable consumers | JetStream is a natural fit when its stream retention choices and durable consumer behavior match the application. | Which retention policy and acknowledgment behavior preserve the required messages and delivery guarantees? |
| Operational footprint and total cost | Neither is universally cheaper or simpler; the result depends on workload, deployment, and operating requirements. | Compare infrastructure, storage, staffing, recovery procedures, and the cost of required integrations using the same workload. |
These are architecture-based selection heuristics, not claims that one platform is always faster, cheaper, or easier to operate. Use your measured results to validate the requirements that matter in your environment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
