Performance Benchmark

This document is based on the AutoMQ Enterprise Edition kernel for testing and compares AutoMQ Enterprise Edition with Apache Kafka in scenarios such as elasticity efficiency, send/receive latency, and cold reads. To replicate and verify the performance test data, please refer to the Overview▸ document to install the AutoMQ BYOC edition.

In this report, the AutoMQ Enterprise Edition uses BYOC deployment and EBS as WAL storage to achieve low-latency message sending and receiving.

Comparison Conclusion

100x Efficiency Improvement

• 300x Efficiency Improvement in Partition Reassignment Compared to Apache Kafka: The partition reassignment speed of AutoMQ is approximately 300 times faster than that of Apache Kafka. AutoMQ transforms Kafka's high-risk routine maintenance actions into automated, nearly imperceptible low-risk operational tasks.

• 4min to 1GiB/s Ultimate Elasticity: AutoMQ's cluster can boost its emergency elasticity from 0 MiB/s to 1 GiB/s in just 4 minutes. This rapid scalability allows the system to accommodate sudden traffic spikes efficiently.

• 200x Cold Read Efficiency over Apache Kafka: AutoMQ optimizes performance by separating reads and writes, achieving a 200-fold reduction in send latency compared to Apache Kafka and a fivefold increase in throughput. AutoMQ seamlessly manages peak shaving and filling for online messaging and offline batch processing scenarios.

10x Cost Savings

• 2x Throughput Limit over Apache Kafka: On identical hardware, AutoMQ delivers twice the maximum throughput of Apache Kafka, with P999 send latency at just one-fourth. In real-time stream processing scenarios, AutoMQ provides faster computational results at a reduced cost.

• 1/11 Billing Cost Compared to Apache Kafka: AutoMQ utilizes Auto Scaling and object storage to reduce costs by 11 times compared to Apache Kafka. With AutoMQ, there's no necessity to provision capacity for peak demand, enabling true pay-as-you-go for both computing and storage.

This report compares the hardware resource costs associated with different solutions for managing the same processing scale. The test cost data for AutoMQ does not include software subscription fees.

Test Preparation

The benchmark test has been improved based on the Linux Foundation's OpenMessaging Benchmark to simulate real user scenarios by providing dynamic workloads. You can find the configurations and workloads for all test scenarios in the GitHub repository.

Configuration Parameters

AutoMQ is set to flush data to disk by default before responding, using the following settings:

acks=all
flush.message=1

AutoMQ Business Edition ensures high data reliability through the EBS multi-replica mechanism, so you don't need to configure multiple replicas on the Kafka side.

Apache Kafka is using version 3.6.0. Following Confluent's guidance, it doesn't set flush.messages = 1. Instead, it relies on a three-replica in-memory asynchronous flush to ensure data reliability (power outages in data centers can lead to data loss), configured as follows:

acks=all
replicationFactor=3
min.insync.replicas=2

Machine Specifications

When considering cost-effectiveness, small instance types combined with EBS are more advantageous than larger machines equipped with SSDs.

For example, small instance r6in.large + EBS versus large instance i3en.2xlarge + SSD:

• i3en.2xlarge, 8 cores, 64 GB memory, network baseline bandwidth 8.4 Gbps, with two 2.5 TB NVMe SSDs, maximum disk throughput of 600 MB/s; price $0.9040/h.

• r6in.large * 5 + 5 TB EBS, 10 cores, 80 GB memory, network baseline bandwidth 15.625 Gbps, EBS baseline bandwidth 625 MB/s; price (compute) 0.1743 * 5 + (storage) 0.08 * 5 * 1024 / 24 / 60 = $1.156/h.

At first glance, the price and performance of the two are almost the same. Considering that in actual production, data is expected to be retained for longer periods, using i3en.2xlarge would require horizontal scaling of compute nodes to increase cluster storage space, which wastes computing resources. With r6in.large + EBS, only the capacity of EBS needs adjustment.

Thus, considering both cost and performance, AutoMQ and Apache Kafka compute both choose r6in.large as the minimum elastic unit for brokers, with storage using GP3 type EBS and Standard S3.

• r6in.large: 2 cores, 16 GB memory, network baseline bandwidth 3.125 Gbps, EBS baseline bandwidth 156.25 MB/s; price $0.1743/h.

• GP3 EBS: The free tier includes 3000 IOPS and 125 MB/s bandwidth. Pricing for storage is $0.08 per GB per month, with additional bandwidth costing $0.040 per MB/s per month and extra IOPS priced at $0.005 per month.

AutoMQ and Apache Kafka have different methods of utilizing EBS:

• AutoMQ uses EBS as a write buffer, requiring only 3 GB of storage, and leverages the free tier for IOPS and bandwidth.

• Apache Kafka stores all its data on EBS, with the required space determined by traffic and retention times in specific test scenarios. Additional EBS bandwidth of 31 MB/s is purchased, which further increases Apache Kafka's unit cost per throughput.

100x Efficiency Improvement

Second-level Partition Reassignment

In a production environment, a Kafka cluster often serves multiple businesses. Fluctuations in business traffic and partition distribution may lead to insufficient cluster capacity or machine hotspots. Kafka operators need to scale the cluster and reassign hotspot partitions to idle nodes to ensure the cluster remains available.

The time taken for partition reassignment determines the efficiency of emergency responses and operations:

• The shorter the partition reassignment time, the quicker the cluster can scale to meet capacity demands, thus reducing the duration of any service impairment.

• Faster partition reassignment shortens the observation period for operators, allowing for quicker feedback and informed subsequent operational decisions.

300x improvement in efficiency: AutoMQ reduces the time required for reassigning a 30 GiB partition compared to Apache Kafka from 12 minutes to just 2.2 seconds.

Testing

This test assesses the reassignment time and the effects of moving a partition containing 30 GiB of data to a node without a replica of that partition, under typical send-consume traffic scenarios using AutoMQ and Apache Kafka. The specific test setup is as follows:

1. Two r6in.large brokers are used to create:

   • • One single-partition, single-replica Topic A, with continuous read and write operations at a throughput of 40 MiB/s.

   • A topic B with 4 partitions and a single replica was used, with a continuous read and write throughput of 10 MiB/s serving as background traffic.

After 13 minutes, the only partition of Topic A was reassigned to another node, with reassignment throughput limited to 100 MiB/s.

Each Apache Kafka broker was additionally mounted with a 320GB 156MiB/s gp3 EBS for data storage.

Driver files: apache-kafka-driver.yaml, automq-for-kafka-driver.yaml

Workload file: partition-reassignment.yaml

AutoMQ Installation Configuration File: partition-reassignment.yaml

Comparison Item	AutoMQ	Apache Kafka
Reassignment Duration	2.2s	12min
Reassignment Impact	Maximum send latency of 2.2s	Continuous send latency within 12min fluctuating from 1ms to 90ms

---

Analysis

The reassignment of AutoMQ partitions involves only uploading the buffered data from EBS to S3 to securely open on a new node, typically uploading 500 MiB within 2 seconds. The duration of AutoMQ partition reassignment is independent of the partition's data volume, averaging around 1.5 seconds. During reassignment, AutoMQ partitions return a NOT_LEADER_OR_FOLLOWER error code to the client. Upon completion, the client updates to the new Topic routing table, internally retrying to send to the new node, temporarily increasing the partition's send latency until it returns to normal levels after reassignment.

Apache Kafka partition reassignment requires copying the partition's replicas to a new node, catching up with new writes while copying historical data. The reassignment duration equals the partition's data volume divided by (the reassignment throughput limit minus the partition's write throughput). In real-world production environments, partition reassignment often takes hours; in this test, the reassignment of a 30 GiB partition took 12 minutes. Besides the lengthy reassignment, Apache Kafka needs to read cold data from the hard disk, and even with throttling, page cache contention can cause fluctuations in send latency, affecting service quality, depicted in the graph as the green curve's jittery portions.

0 -> 1 GiB/s Extreme Elasticity

Kafka administrators typically plan Kafka cluster capacity based on historical experience, yet unexpected surges in traffic due to hot events and activities continually arise. In such cases, rapid cluster expansion and partition rebalancing become necessary to handle sudden spikes in traffic.

With extreme elasticity, AutoMQ clusters can automatically scale from 0 MiB/s to 1 GiB/s in just 4 minutes.

Test

The purpose of this test is to measure the auto-scaling surge elasticity of AutoMQ as it automatically scales from 0 MiB/s to 1 GiB/s. The specific test scenario is as follows:

1. The cluster initially has only 1 broker, with the auto-scaling surge capacity set to 1 GiB/s, and a topic with 1,000 partitions is created.

2. OpenMessaging is started to directly set the sending traffic to 1 GiB/s.

Driver files: apache-kafka-driver.yaml, automq-for-kafka-driver.yaml

Load file: emergency-scaling.yaml

AutoMQ configuration file for installation: emergency-scaling.yaml

Analysis Item	Monitoring Alert	Batch Expansion	Auto Balancing	Total
0 -> 1 GiB/s Elastic Time	70s	80s	90s	4min

---

Analysis

AutoMQ's cluster capacity is typically maintained at 80% of the cluster's threshold using Auto Scaling's target tracking policy. In unexpected scenarios with sudden traffic spikes, the target tracking policy may not immediately fulfill the capacity demands. Auto Scaling offers an emergency strategy in which the cluster will immediately scale to the target capacity when the cluster threshold exceeds 90%.

In this test, Auto Scaling's emergency strategy scaled the cluster capacity to the target capacity in 4 minutes:

• 70s: AWS CloudWatch, with the highest monitoring precision of 1 minute, detects the cluster threshold exceeding 90% and triggers an alert.

• 80s: AWS performs a bulk scale-out of nodes to the target capacity, and brokers complete node registration.

• 90s: AutoMQ's Auto Balancing detects traffic imbalance among nodes and completes automatic traffic rebalancing.

• Cluster capacity meets the requirement of 1 GiB/s, and sending time returns to benchmark time.

Catch-up Read

Catch-up read is a common scenario in messaging and streaming systems:

• In messaging, messages are typically used to decouple business processes and even out peaks and troughs. Smoothing peaks requires that the message queue holds the data sent upstream, allowing it to be consumed gradually downstream. In this scenario, the downstream systems read "catch-up" data that are cold and not in memory.

• In streams, periodic batch processing tasks may need to start scanning and computing data from several hours or even a day ago.

• There are additional fault scenarios: the consumer goes offline for several hours due to a failure and then comes back online; consumer logic issues are fixed, followed by a rewind to consume historical data.

Catch-up reads focus mainly on two aspects:

• The speed of catch-up reads: The faster the catch-up reads, the more quickly the consumer can recover from the failure, and the faster batch processing tasks can produce analytical results.

• Isolation of reads and writes: Catch-up reads should aim to minimally impact the production rate and latency.

With a 200x efficiency improvement, AutoMQ's read-write separation compared to Apache Kafka in catch-up read scenarios reduced sending time from 800ms to 3ms and shortened catch-up time from 215 minutes to 42 minutes.

Test

This test evaluates the catch-up read performance of AutoMQ and Apache Kafka using an identical cluster size. The test scenarios are outlined as follows:

1. Deploy a cluster with 20 Brokers and create a Topic with 1000 partitions.

2. Continuously send data at a throughput of 800 MiB/s.

3. After sending 4 TiB of data, initiate the consumer to consume from the earliest offset.

Each Apache Kafka broker is equipped with a separate 1000GB 156MiB/s gp3 EBS for data storage.

Driver files: apache-kafka-driver.yaml, automq-for-kafka-driver.yaml

Workload file: catch-up-read.yaml

AutoMQ installation config file: catch-up-read.yaml

Comparison Item	Send Latency During Catch-up Read	Impact on Send Throughput During Catch-up Read	Peak Throughput During Catch-up Read
AutoMQ	Less than 3ms	Read-write isolation, maintains 800 MiB/s	2500 ~ 2700 MiB/s
Apache Kafka	Approximately 800ms	Interference, drops to 150 MiB/s	2600 ~ 3000 MiB/s (at the expense of writes)

---

---

Analysis

• In an equivalent cluster size scenario, during catch-up reads, AutoMQ's sending throughput remains stable, whereas Apache Kafka's sending throughput drops by 80%. This is because Apache Kafka performs disk reads during catch-up without IO isolation, consuming the read-write bandwidth of AWS EBS. This reduces the bandwidth available for writing to disk, thereby lowering sending throughput. In contrast, AutoMQ separates reads and writes by utilizing object storage for catch-up reads instead of the disk, which doesn't consume disk read-write bandwidth and thus doesn't affect sending throughput.

• For the same cluster size, during catch-up reads, the average send latency for AutoMQ rises by about 0.4 ms compared to just sending, while Apache Kafka's latency surges to around 800 ms. This spike in send latency for Apache Kafka can be attributed to two factors: first, as noted earlier, catch-up reads consume AWS EBS read-write bandwidth, leading to decreased write throughput and increased latency; second, during catch-up reads, retrieving cold data from the disk contaminates the page cache, similarly resulting in higher write latency.

• It's important to note that when catching up to read 4 TiB of data, AutoMQ took 42 minutes, whereas Apache Kafka took just 29 minutes. The shorter time for Apache Kafka can be attributed to two reasons:

  • During catch-up reads, Apache Kafka's sending traffic was reduced by 80%, which decreased the amount of data it needed to handle while catching up.

  • Apache Kafka does not implement I/O isolation, prioritizing reading speed over maintaining the sending rate.

  If we assume Apache Kafka implements I/O isolation, meaning it reads while maintaining the sending rate as much as possible, the calculation would proceed as follows:

  • Assume that during catch-up reads, Apache Kafka maintains a sending rate of 700 MiB/s. Considering triple-replica writes that occupy EBS bandwidth, it would be 700 MiB/s * 3 = 2100 MiB/s.

  • The total EBS bandwidth in the cluster is 156.25 MiB/s * 20 = 3125 MiB/s.

  • The bandwidth available for reading is 3125 MiB/s - 2100 MiB/s = 1025 MiB/s.

  • In a catch-up read scenario where data is simultaneously sent and read, reading 4 TiB of data would take 4 TiB * 1024 GiB/TiB * 1024 MiB/GiB / (1025 MiB/s - 700 MiB/s) / 60 s/min = 215 min.

  Apache Kafka requires 215 minutes to catch up on reading 4 TiB of data without significantly impacting the sending process, which is 5 times longer than with AutoMQ.

10x Cost Savings

Kafka costs primarily consist of computing and storage. AutoMQ has theoretically achieved optimal cloud cost savings in these areas, offering up to 10x cost savings compared to Apache Kafka:

• Computing

  • Spot instances save up to 90%: AutoMQ benefits from stateless Brokers, enabling the extensive use of Spot instances to reduce single-node computing costs.

  • EBS multi-replica reliability saves up to 66%: AutoMQ leverages EBS multi-replicas to ensure high data reliability. Compared to ISR three replicas, computing instances can achieve up to a 1:3 ratio in cost savings.

  • Auto Scaling: AutoMQ employs a target tracking strategy to scale the cluster dynamically in response to real-time traffic changes.

• Storage

  • Save up to 93% with object storage: AutoMQ stores nearly all data in object storage, potentially reducing storage costs by up to 93% compared to triple-replicated EBS.

Fixed Scale

AutoMQ boasts a maximum throughput that is 2x that of Apache Kafka, with a P999 latency for sending that is just 1/4 of Apache Kafka's.

Testing

This test assesses the performance and throughput limits of AutoMQ and Apache Kafka across various traffic scales using the same cluster size. The test scenarios are as follows:

1. The cluster is configured with 23 Brokers and a single Topic with 1,000 partitions.

2. Initiate 1:1 read-write traffic at rates of 500 MiB/s and 1 GiB/s, respectively. Additionally, evaluate the maximum throughput for AutoMQ at 2,200 MiB/s and Apache Kafka at 1,100 MiB/s.

Each Apache Kafka broker is also equipped with a 500GB, 156 MiB/s gp3 EBS for data storage.

Driver files: apache-kafka-driver.yaml, automq-for-kafka-driver.yaml

Load files: tail-read-500m.yaml, tail-read-1024m.yaml, tail-read-1100m.yaml, tail-read-2200m.yaml

AutoMQ installation configuration file: tail-read.yaml

Comparison Item	Maximum Throughput	500 MiB/s Send Time P999	1 GiB/s Send Time P999
AutoMQ	2200 MiB/s	13.829 ms	25.492 ms
Apache Kafka	1100 MiB/s	55.401 ms	119.033 ms

---

---

Detailed data on send time and E2E time:

Pub Latency(ms)	500 MiB/s		1 GiB/s		Throughput Limit
Comparison Item	AutoMQ	Apache Kafka	AutoMQ	Apache Kafka	AutoMQ 2200 MiB/s	Apache Kafka 1100 MiB/s
AVG	2.116	1.832	2.431	3.901	5.058	4.591
P50	1.953	1.380	2.118	2.137	3.034	2.380
P75	2.271	1.618	2.503	3.095	3.906	3.637
P95	2.997	2.618	3.859	8.254	9.555	10.951
P99	6.368	12.274	8.968	50.762	37.373	60.207
P999	13.829	55.401	25.492	119.033	331.729	134.814
P9999	32.467	76.304	65.24	233.89	813.415	220.280

---

E2E Latency(ms)	1 GiB/s		Throughput Limit
Comparison Item	AutoMQ	Apache Kafka	AutoMQ 2200 MiB/s	Apache Kafka 1100 MiB/s
AVG	4.405	4.786	6.858	5.477
P50	3.282	3.044	4.828	3.318
P75	3.948	4.108	6.270	4.678
P95	10.921	9.514	12.510	11.946
P99	26.610	51.531	34.350	60.272
P999	53.407	118.142	345.055	133.056
P9999	119.254	226.945	825.883	217.076

Analysis

1. With the same cluster size, AutoMQ's maximum throughput is double that of Apache Kafka.

AutoMQ ensures high data reliability through multiple replicas based on EBS at the underlying level, without requiring additional replication at the upper layer. In contrast, Apache Kafka relies on ISR with three replicas for high data reliability. Assuming there are no CPU and network bottlenecks, both AutoMQ and Apache Kafka operate at maximum disk bandwidth, with AutoMQ having a theoretical throughput limit that is three times greater than Apache Kafka's.

In this test, AutoMQ needs to upload data to S3, which results in higher CPU usage compared to Apache Kafka, causing AutoMQ's CPU to become a bottleneck first. The total disk bandwidth limit for 23 r6in.large instances is 3588 MB/s. Apache Kafka's theoretical three-replica send limit is 1196 MB/s, causing Kafka’s disk to be the first bottleneck. Ultimately, the stress test results showed that AutoMQ achieved throughput twice that of Apache Kafka.

With the same cluster size and traffic of 500 MiB/s, AutoMQ's send latency at P999 is one-fourth of Apache Kafka's. Even at double the traffic rate (500 MiB/s : 1024 MiB/s), AutoMQ's send latency at P999 remains half of Apache Kafka's.

• AutoMQ uses Direct IO to bypass the file system and write directly to the bare EBS devices, eliminating file system overhead and achieving more stable send latency.

• Apache Kafka employs Buffered IO to write data to the page cache, marking it as successful once it reaches the page cache, while the operating system flushes the dirty pages to disk in the background. File system overhead, consumer cold reads, and the uncertainty of page cache misses can all contribute to fluctuations in send latency.

3. At a throughput of 1 GiB/s, AutoMQ can reduce computation costs by up to 20x and storage costs by up to 10x compared to Apache Kafka.

• Computation: AutoMQ uses EBS only as a buffer for writing to S3 and uploads data to S3 upon shutdown, accomplishing this within 30 seconds. This strategy allows AutoMQ to fully leverage Spot instances, which can be up to 90% cheaper than On-Demand instances. Additionally, AutoMQ's throughput per machine is twice that of Apache Kafka, resulting in up to a 20x reduction in computation costs compared to Apache Kafka.

• Storage: AutoMQ stores almost all data in S3, which charges based on the actual data stored. In contrast, Apache Kafka stores data on disk with three replicas, typically reserving at least 20% extra disk space in production environments. AutoMQ reduces storage cost per GB by up to a factor of 1 / (0.023 S3 unit price / (3 replicas * 0.08 EBS unit price / 0.8 disk water level)) = 13x compared to Apache Kafka. Even after accounting for the cost of S3 API calls, AutoMQ achieves up to a 10x reduction in storage costs compared to Apache Kafka.

Moreover, Apache Kafka's maximum throughput testing fills the disk bandwidth entirely, requiring reserved disk bandwidth for partition reassignment and cold data catch-up reads in production environments, which decreases the write water level limit. In contrast, AutoMQ separates read and write operations, allowing catch-up reads from S3 to use network bandwidth, so all disk bandwidth can be allocated to writing. As a result, the production water level limit remains consistent with the stress test levels.

Auto Scaling

With up to an 11x ultimate cost reduction, AutoMQ leverages Auto Scaling and object storage to achieve true pay-as-you-go pricing for computation and storage.

Test

This test simulates peak-and-valley production loads to evaluate the cost and performance of AutoMQ using the Auto Scaling target tracking strategy. The test scenarios are as follows:

1. Set up the cluster on AWS using the AutoMQ Installer.

2. Create a Topic with 256 partitions and a retention time of 24 hours.

3. Perform a performance test with dynamic traffic in a 1:1 read/write ratio as follows:

   1. The standard traffic is 40 MiB/s.

   2. From 12:00 to 12:30, the traffic increases to 800 MiB/s, and it returns to 40 MiB/s by 13:00.

   3. From 18:00 to 18:30, the traffic rises to 1200 MiB/s, and it reverts back to 40 MiB/s by 19:00.

Driver files: apache-kafka-driver.yaml, automq-for-kafka-driver.yaml

Load file: auto-scaling.yaml

AutoMQ Installation Configuration File: auto-scaling.yaml

Cost Comparison between AutoMQ and Apache Kafka under the Same Load:

Cost Category	Apache Kafka (USD / month)	AutoMQ (USD / month)	Multiplier
Compute	3,054.26	201.46	15.2
Storage	2,095.71	257.38	8.1
Total	5,149.97	458.84	11.2

---

Analysis

This test provides an empirical account of a cost bill in AWS East, utilizing a pay-as-you-go model for both computing and storage:

• Compute: Employing the target tracking policy of Auto Scaling, compute nodes dynamically scale according to the cluster traffic, thereby maintaining the cluster load at 80% on a minute-by-minute basis (AWS monitoring alerts occur at a minute-level granularity, and combined with monitoring delay, the tracking precision is approximately 2 minutes).

• Storage: Nearly all data is stored on S3, with storage costs mainly consisting of S3 storage fees and S3 API call fees. S3 storage fees are directly proportional to the volume of data written and the data retention time, while S3 API call fees relate to the write volume. Both S3 storage fees and S3 API call fees follow a pay-as-you-go model.

If you build a cluster with Apache Kafka consisting of three replicas to handle a peak daily traffic of 1 GiB/s, under the same traffic model, Apache Kafka will require at least the following monthly expenditure:

• Calculations: Due to the difficulty of dynamic scaling, capacity must be prepared for peak usage. Broker cost: r6in.large at a unit price of $0.17433 per hour * 730 hours per month * 23 instances = $2,927.00.

• Storage:

  • Storage cost: (Total data size 6,890.625 GB x 3 replicas / disk water level 80%) x EBS unit price $0.08 per GB per month = $2,067.19.

  • Storage bandwidth cost: MB bandwidth unit price $0.04 x additional purchase bandwidth 31 MB/s x 23 EBS volumes = $28.52.

Cost Category		Apache Kafka (USD / month)	AutoMQ (USD / month)	Multiplier
Calculation	Controller	127.26	127.26	1.0
	Broker	2,927.00	74.20	39.4
	Total	3,054.26	201.46	15.2
Storage	EBS Storage	2,067.19	0.43
	EBS Throughput	28.52
	S3 Storage		158.48
	S3 API		98.47
	Total	2,095.71	257.38	8.1
Total		5,149.97	458.84	11.2

Summary

This benchmark illustrates that AutoMQ, after redesigning Kafka for the cloud, offers substantial improvements in both efficiency and cost savings compared to Apache Kafka:

1. 100x increase in efficiency:

   1. In partition reassignment scenarios, AutoMQ reduced the 30GB partition reassignment time from Apache Kafka's 12 minutes to 2.2 seconds, achieving a 300x increase in efficiency.

   2. With exceptional elasticity, AutoMQ can automatically scale out from 0 to 1 GiB/s in just 4 minutes to meet target capacity.

   3. In scenarios involving catching up on historical data reads, AutoMQ's read-write separation optimizes average send latency by 200x, reducing it from 800ms to 3ms, and the catch-up read throughput is 5 times that of Apache Kafka.

2. Achieve 10x cost savings:

   5. At a fixed scale, AutoMQ's throughput limit reaches up to 2200 MiB/s, which is 2 times that of Apache Kafka. Meanwhile, the P999 sending latency is only 1/4 of that of Apache Kafka.

   6. In dynamic load scenarios ranging from 40 MiB/s to 1200 MiB/s, AutoMQ achieves significant savings in compute resources during low traffic periods through Auto Scaling, resulting in an 11x reduction in billing costs compared to Apache Kafka.

Additional Notes

• AutoMQ supports AWS Graviton instances, and this performance comparison is equally applicable to instances supported by Graviton.

• In the cloud resource cost comparison, only compute and storage were considered. In practice, Apache Kafka in AWS environments incurs cross-AZ traffic charges, which AutoMQ can eliminate through its cross-AZ routing component. For more details, refer to Save cross-AZ traffic costs with AutoMQ▸