Introduction

When we started building Conduit, our goal was to create a viable replacement for Kafka Connect. But lighter, faster, and easier to use. Now, with a mature feature set and the upcoming 1.0 release, we’ve turned our focus to performance and producing benchmarks comparing Conduit with Kafka Connect.

We started with MongoDB and Kafka, then tested Postgres to Kafka. And now, in this blog post, we will show MySQL to Kafka benchmarks, for Conduit against Kafka Connect across various EC2 instances, highlighting how Conduit performs under real-world conditions, especially when efficiency, resource usage, cost, and simplicity matter most.

Benchmarks

Metrics

Our benchmarks focus on three metrics: message throughput, CPU utilization, and Memory Usage. Record throughput within Conduit is tracked using Conduit’s metrics, the throughput of Kafka messages is measured using JMX in the Kafka broker, and resource usage is monitored with the information that Docker exposes.

Setup

To ensure fairness and realism in our comparison, we conducted comprehensive benchmarks using Benchi on different EC2 instance types: c7a.large, and c7a.xlarge, each provisioned with 40GB gp3 EBS volume.

The pipelines’ configurations used for both Conduit and Kafka Connect are added to another repository called streaming-benchmarks, which also contains the benchmark results.

The amount of data we inserted into the MySQL instance for each test was 3 million records with the following schema:

CREATE TABLE users (
	id INT AUTO_INCREMENT PRIMARY KEY,
	username VARCHAR(50) NOT NULL,
	email VARCHAR(100) UNIQUE NOT NULL,
	first_name VARCHAR(50),
	last_name VARCHAR(50)
);

Benchmark Results

Test #1:

Using the EC2 instance c7a.large, 40GB (2 vCPU, 4 GiB RAM), which will have the least resources used throughout these benchmarks.

Results:

This highlights Conduit's capability to perform efficiently despite limited resources. It successfully handled the MySQL to Kafka pipeline at a robust message rate, consuming low memory. On the other hand, Kafka Connect couldn’t even start due to insufficient resources.

Test #2:

Using the EC2 instance c7a.xlarge, 40GB: (4 vCPU, 8 GiB RAM)

Results:

When scaling up to a more powerful EC2 instance (c7a.xlarge), both Conduit and Kafka Connect were able to run the MySQL to Kafka pipeline. While Kafka Connect delivered slightly higher throughput, around 135K msg/sec, Conduit kept up with an impressive ~89K msg/sec**, all while maintaining an** extremely efficient resource usage:

• Conduit used 75% less memory compared to Kafka Connect (just 500–600 MB vs. over 2 GB).
• Conduit sustained its throughput with slightly higher CPU, showcasing how it trades CPU for memory, avoiding the usual heavyweight overhead that Kafka Connect tends to have.

Key Findings: Conduit Delivers Efficient Performance at Scale

Across all tested EC2 instance types, from low-resource to high-resource environments, Conduit consistently proves to be a lean, reliable, and production-ready tool for MySQL to Kafka pipeline.

• On c7a.large, Kafka Connect couldn’t even start, while Conduit ran smoothly, delivering solid throughput with minimal resource usage.
• On c7a.xlarge, Kafka Connect achieved higher throughput, but Conduit held close, using ~75% less memory while maintaining competitive performance. Even though Conduit used more CPU (around 80% vs Kafka Connect’s 60%), it did so intentionally and efficiently, making better use of available system resources.

If you're building streaming pipelines and care about efficiency, scalability, and cost, Conduit isn't just an alternative, it's the better tool for the job.

Say Hello!

Curious about benchmarks? About Conduit? Have ideas for new tests, or have questions about other connectors? Drop us a “hello!” on our Discord channel or open a GitHub discussion!