The Edge Computing Bottleneck
Running high-throughput telemetry pipelines on edge devices like Raspberry Pis, Advantech gateways, and embedded x86/ARM boxes presents unique challenges. Traditional stream processing engines often fail to meet the stringent resource constraints and performance demands of these environments. I-Dacs Labs, facing this reality, identified two primary culprits: JVM-based engines and Go-based alternatives.
JVM engines, exemplified by Apache Flink, offer impressive throughput but are resource-hungry, typically requiring over 1GB of RAM and taking upwards of 20 seconds to boot. This makes them impractical for deployment on small, power-constrained industrial hardware. The sheer overhead is a non-starter for many edge use cases.
Go engines, including upstream eKuiper, Benthos, and Telegraf, fare better in terms of resource usage. However, they introduce their own set of problems. Continuous Stop-The-World garbage collection (GC) sweeps can lead to unacceptable tail latency jitter, a critical issue for real-time data processing. Furthermore, under burst loads—where sensor data can surge to 10k–100k events per second—Go's channel buffer saturation has been observed to cause silent packet loss. This means data simply disappears without any indication, a critical failure for monitoring and control systems.
These limitations pushed I-Dacs Labs to seek a more robust and efficient solution. The decision was made to undertake a complete rewrite of the engine, opting for a language known for its performance, memory safety, and concurrency capabilities: Rust. This led to the development of rekuiper, a new stream processing engine built from the ground up in Rust.
Introducing Rekuiper: Performance in Rust
The rewrite in Rust, dubbed rekuiper, has yielded dramatic improvements across key performance metrics. The goal was to create an engine that not only matched but significantly surpassed existing solutions in throughput and latency while drastically reducing resource consumption. The results speak for themselves.
Rekuiper achieves a throughput of 425,000 events per second (eps). This figure is particularly impressive when compared to its predecessors and competitors. The memory footprint is astonishingly low, requiring only 8MB of RAM. This is a fraction of what JVM engines demand and significantly less than many Go-based alternatives, making it ideal for resource-starved edge devices. Boot times have also been slashed to just 13 milliseconds, enabling rapid deployment and recovery scenarios.
This performance leap is attributed to Rust's inherent characteristics. Rust offers compile-time memory safety guarantees without a garbage collector, eliminating GC-induced latency spikes. Its efficient concurrency model allows for high-performance parallel processing without the risk of data races or deadlocks. The language's focus on zero-cost abstractions means that high-level code compiles down to highly optimized machine code, similar to C or C++, but with added safety.
Benchmarking Against the Giants
To validate these claims, rekuiper was benchmarked against established players in the stream processing space: Apache Flink, the original Go-based eKuiper, and Benthos. The benchmarks focused on throughput, memory usage, and boot time.
Against Apache Flink, rekuiper demonstrates a clear advantage in resource efficiency. While Flink is known for its powerful distributed processing capabilities, its substantial RAM requirements render it unsuitable for many edge deployments. Rekuiper's 8MB RAM usage is orders of magnitude lower, making it a viable option for even the most constrained devices.
The comparison with Go-based eKuiper and Benthos highlights rekuiper's superiority in both latency and throughput. The elimination of GC pauses in Rust means more consistent, predictable performance, crucial for applications where even minor delays can have significant consequences. Furthermore, rekuiper avoids the channel buffer saturation issues that plagued the Go implementations, ensuring no data loss under heavy load. The 425k eps throughput achieved by rekuiper significantly outpaces what was observed with the Go alternatives, especially under peak conditions.
The 13ms boot time is another critical differentiator. This near-instantaneous startup allows for rapid initialization and recovery, a vital feature for edge devices that may experience intermittent power or network connectivity. Compared to the seconds-long boot times of JVM engines, this represents a paradigm shift in deployability for edge applications.
Implications for Edge Computing
The development of rekuiper has significant implications for the future of edge computing. By providing a high-performance, low-resource stream processing engine, it removes a major bottleneck for deploying sophisticated data processing capabilities directly on edge devices.
This opens up new possibilities for real-time analytics, anomaly detection, predictive maintenance, and local control loops that were previously infeasible due to hardware limitations. Developers can now implement complex filtering, aggregation, and transformation logic directly at the data source, reducing reliance on cloud connectivity and minimizing latency.
The choice of Rust is also noteworthy. It signals a growing trend towards using Rust for systems programming where performance and safety are paramount. As more libraries and frameworks mature, Rust is increasingly becoming the language of choice for building reliable, high-performance infrastructure components, including those destined for the edge.
What remains to be seen is how quickly other projects will adopt Rust for similar low-level, high-performance tasks, and whether the ecosystem can mature to offer the same breadth of integrations and ease of use as longer-established languages like Go and Java in the stream processing domain.