Rust rewrite of eKuiper claims 425k events/sec and 8MB RAM in edge benchmarks

What happened

A team at I-Dacs Labs has published rekuiper, an open-source rewrite of the LF Edge eKuiper stream-processing engine written in Rust. In a dev.to post dated 10 September 2026, the group reports that version 0.421-beta processed 500,000 telemetry records at roughly 425,000 events per second while consuming about 8 MB of memory and booting its internal daemon in around 13 milliseconds.

The problem it targets

According to the post, I-Dacs Labs runs high-throughput telemetry pipelines on constrained edge hardware, including Raspberry Pis, Advantech gateways and embedded x86 and ARM boxes. They had used the Go-based eKuiper for local stream processing, covering SQL filtering, sliding windows, and MQTT and Kafka sinks, but kept running into limits they describe as a structural tradeoff in edge computing.

On one side, JVM engines such as Apache Flink deliver strong throughput but require more than 1 GB of RAM and over 20 seconds of boot time, which the authors consider unusable on small industrial hardware. On the other, Go engines are lighter, but the post reports tail-latency jitter from garbage-collection sweeps and, more seriously, silent packet loss under burst sensor loads of 10,000 to 100,000 events per second when Go channel buffers fill up.

What the rewrite contains

The new engine is built around a lock-free stream bus called StreamBus, Tokio-based asynchronous actors for rule execution, and bounded actor queues feeding sinks, a design the authors say removes garbage-collection pauses at runtime.

The project claims full drop-in parity with upstream eKuiper: compatibility with the existing eKuiper Manager web UI, OpenAPI 3.0 schemas and standard streaming SQL, with all 98 REST endpoints implemented and no stubs. Reported footprint figures include a 9.60 MB stripped static binary, roughly 6 to 8.2 MB of idle RAM, an internal daemon bootstrap of 12.5 to 14.5 ms, and 123 ms end to end from process spawn to socket ready. The code is dual-licensed under MIT and Apache-2.0.

Benchmark results

All engines were run on the same Linux machine, a WSL2 Ubuntu x86_64 setup, with an identical pipeline: parse 500,000 JSON events, compute a temperature conversion, filter values above a threshold, project two fields and write to a sink.

Engine	Runtime	Elapsed	Throughput	Drops	Memory
rekuiper 0.421	Rust	1.176 s	425,308 eps	0	~8 MB
Apache Flink	JVM	2.144 s	233,209 eps	0	~1,022 MB
Telegraf	Go	8.194 s	61,019 eps	0	~50 MB
Upstream Go eKuiper	Go	11.290 s	44,287 eps	72,921 (14.6%)	~45 MB
Redpanda Connect	Go	19.236 s	25,993 eps	0	~38 MB

The post's headline names Benthos, while the table lists Redpanda Connect, the same project under its current name.

The authors highlight three findings. First, upstream Go eKuiper dropped 72,921 of the 500,000 records, about 14.6 percent, under sustained burst ingestion because of channel saturation, while rekuiper processed every record and was described as 9.6 times faster. Second, Flink reached 233k events per second but its JobManager and TaskManager consumed more than 1 GB of RAM; rekuiper is claimed to exceed its single-core throughput while using roughly 125 times less memory. Third, on cold boot, rekuiper's roughly 13 ms internal startup compares with 1.2 seconds for Go eKuiper and 20 seconds for Flink, according to the post.

Reading the numbers carefully

These are self-reported figures from the project's authors, produced with beta software on a single WSL2 environment using one fairly simple pipeline. There is no independent verification yet, and the table does not show results on the ARM edge hardware the project says it targets. The fact that the authors' engine wins every column is itself a reason for caution, and the drop figure for upstream eKuiper applies only to this particular burst test. On the positive side, the repository ships reproduction scripts and Docker configurations, and the full suite can be rerun with a single script, which lowers the barrier for anyone wanting to check the claims.

Why it matters

Edge stream processing forces a real compromise: JVM engines are too heavy for small devices, while Go engines can introduce latency jitter or, if these results hold, silent data loss. A Rust rewrite that keeps the same SQL dialect, REST API and management UI would cut migration cost to near zero for existing eKuiper deployments, and a 13 ms boot matters for devices that sleep between workloads or recover from power cycles. The reported 14.6 percent loss rate for upstream eKuiper is the most consequential claim, since dropping sensor readings is usually worse than processing them slowly. Even for skeptics, the release adds a data point to the Rust-versus-Go conversation in infrastructure tooling, and the published benchmark scripts set a reproducibility standard that similar announcements rarely match.