iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Rust rewrite of LF Edge eKuiper, called rekuiper, reportedly handled 500,000 telemetry records at 425,308 events per second while using about 8 MB of memory. Those figures come from the project author’s single-machine benchmark, not an independent test. The headline’s “13 ms boot” refers to internal daemon bootstrap; the reported time from process launch to a ready socket was 123 ms.
What was tested—and who reported it?
In a September 10, 2026 article on DEV Community, Ankur Kumar Pandey described rekuiper v0.421-beta, a Rust rewrite of LF Edge eKuiper for local telemetry processing. The article says the benchmark used WSL2 with Ubuntu on x86_64 and ran the same 500,000-record JSON workload through each engine: parse events, calculate temp * 1.8 + 32, filter for temp > 20.0, project id and temp_f, then send the output to a sink. Read Pandey’s benchmark article.
The results below are figures reported by the project’s author. They are not independently reproduced measurements, and the page’s details are available here through its indexed rendering.
How did rekuiper compare in the reported run?
| Engine named in the article | Runtime | Elapsed for 500,000 records | Reported throughput | Reported drops | Reported memory |
|---|---|---|---|---|---|
| rekuiper 0.421 | Rust | 1.176 s | 425,308 events/sec | 0 (0.0%) | about 8 MB |
| Apache Flink | Java / JVM | 2.144 s | 233,209 events/sec | 0 (0.0%) | about 1,022 MB |
| Telegraf | Go | 8.194 s | 61,019 events/sec | 0 (0.0%) | about 50 MB |
| Upstream Go eKuiper | Go | 11.290 s | 44,287 events/sec | 72,921 (14.6%) | about 45 MB |
| Redpanda Connect | Go | 19.236 s | 25,993 events/sec | 0 (0.0%) | about 38 MB |
For this workload, the author’s report places rekuiper first in throughput and lowest in reported memory, with no recorded drops. Upstream Go eKuiper is the only entry shown with dropped records: 72,921, or 14.6%. These comparisons describe this particular run; they do not establish a general ranking of the engines.
#1 Best Overall
What does “13 ms boot” mean?
The article reports an internal daemon bootstrap time of 12.5–14.5 ms. It separately reports 123 ms from operating-system process spawn until the service had a ready socket. These are different measurements: the shorter figure does not include the full process-launch-to-ready interval.
What the results do—and do not—establish
The test is a narrow workload snapshot
The published comparison covers one 500,000-record batch workload on WSL2 / Ubuntu x86_64. It does not show how the engines perform on a physical Raspberry Pi, an Advantech gateway, or an embedded ARM system. Nor does the described run establish long-duration stability, recovery from network failures, or performance across a broader range of stateful streaming workloads.
Rank #2
The explanation for dropped events is the author’s account
Pandey attributes upstream eKuiper’s reported drops to Go-channel saturation and credits rekuiper’s queues and architecture for its behavior. The benchmark report does not independently verify that causal explanation, so it should be read as the author’s interpretation rather than a separately established finding.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsVersion and compatibility claims need checking
The article presents rekuiper as v0.421-beta and describes a lock-free StreamBus, Tokio asynchronous actors for rule execution, bounded sink queues, and no runtime garbage collector. It also claims compatibility with the eKuiper Manager Web UI, OpenAPI 3.0 schemas, standard streaming SQL, and 98 REST endpoints. Those are claims in the article; parity and compatibility were not independently verified here. Confirm the capabilities of the exact release you intend to deploy.
Rank #3
How to use this comparison when choosing a stream processor
- Match the workload. Use your event shape, transformations, filters, windows, sinks, and expected volume rather than treating this JSON pipeline as a proxy for every deployment.
- Measure on the target hardware. The reported environment was WSL2 / Ubuntu x86_64, not a physical edge device. For a Raspberry Pi or other gateway, run your own test on the specific hardware and operating system.
- Track more than throughput. Record elapsed time, memory, dropped events, and startup timing, and define what “ready” means. Include both internal initialization and process-spawn-to-ready time if startup matters.
- Test operational behavior. A short batch run does not answer questions about sustained load, queue pressure, recovery, or stateful processing. Exercise those cases before relying on a benchmark result for production.
The article says rekuiper is intended for local telemetry processing, including SQL filtering, sliding windows, and MQTT or Kafka sinks on edge systems. A Raspberry Pi may be a platform for a reader’s own exploration, but this benchmark did not test one and does not identify a particular model.
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.
