DEV Community: Ankur Kumar Pandey

rekuiper 0.500: Moving the Engine Hot Path to RAM and Finding its Exact Physical Limits (up to 200k msg/s)

Ankur Kumar Pandey — Mon, 21 Sep 2026 23:39:35 +0000

When we published our earlier benchmarks for rekuiper (our Rust reimplementation of LF Edge eKuiper for edge gateways and IoT hubs), the numbers answered our first question: on five real-world MQTT workloads, memory stayed bounded between 5 and 10 MB while Go-based engines climbed to hundreds of megabytes or failed.

In that test, rekuiper sustained 100,000 messages per second on a single pinned core. At offered 200,000 msg/s, however, it dropped packets or backlogged upstream.

Saying "100k passed and 200k failed" left a massive 100,000 msg/s blind spot. Is the true ceiling 105k? 140k? 195k? And why did it choke at higher rates when the CPU wasn't fully maxed out on every workload?

When we profiled the bottleneck under burst loads, the culprit wasn't stream parsing or window math. It was the disk.

Even when an edge stream engine's data plane runs in memory, typical implementations still touch disk for metadata: checking SQLite tables for stream and rule definitions, resolving auth keys, reading configuration YAMLs, or persisting rule state changes. On a developer NVMe drive, SQLite lookups take microseconds. On an industrial gateway running off slow eMMC flash or a microSD card, a batch of flash writes causes I/O wait spikes that stall the Tokio runtime thread.

For v0.500-beta, we rebuilt the engine's internal catalog and hot paths around an in-memory Redis-style architecture, tuned our storage engine to be zero-contention, and then ran a hierarchical search with 1,000 msg/s resolution under a strictly bounded Mosquitto broker to find the exact physical limit of every workload.

Here is what we built, what we measured, and where single-core stream processing actually hits physical walls.

1. The Bottleneck: Why Disk Kills Edge Ingest

In eKuiper and similar edge software, metadata (streams, rules, schemas, auth) is stored in a key-value store or an embedded SQLite database.

Under moderate load (5k–20k msg/s), querying SQLite to validate a rule or look up a schema is unnoticeable. But when 100,000+ messages per second hit an edge machine:

Lock Contention: When multiple concurrent connections or rules access SQLite simultaneously, lock acquisition overhead adds tail latency.
Flash Storage Stalls: Embedded devices (Raspberry Pi, industrial gateways) do not have enterprise SSD write queues. If the engine writes checkpoint state or logs to flash while simultaneously servicing network buffers, the OS I/O scheduler blocks threads.
Queue Backpressure: When a stream processor stalls for even 10 milliseconds waiting on disk, a 150k msg/s MQTT ingress generates a 1,500-message backlog in the socket buffer. Under QoS 0, Mosquitto drops those packets.

If we wanted to push edge ingestion beyond 100k msg/s on a single core, the hot path could not touch the filesystem at all.

2. What Changed in v0.500

Redis-Style In-Memory Catalog (`MemoryCatalog`)

We separated metadata persistence from metadata reads:

// crates/rekuiper-core/src/catalog.rs
pub struct MemoryCatalog {
    streams: parking_lot::RwLock<HashMap<String, StreamDefinition>>,
    tables: parking_lot::RwLock<HashMap<String, TableDefinition>>,
    rules: parking_lot::RwLock<HashMap<String, RuleDefinition>>,
}

On daemon startup, the catalog hydrates all streams, tables, and active rules from SQLite into memory once.
During execution, the stream bus, rule evaluators, and REST query endpoints read directly from RwLock<HashMap>, completing lookups in nanoseconds with zero system calls and zero disk I/O.
Rule mutations update memory first and asynchronously commit to SQLite in the background.

Zero-Disk Hot Path & Caching

Auth Token Cache: Public RSA keys used for JWT signature verification (KUIPER_AUTH_PUBLIC_KEY_FILE) are parsed and cached in memory. Ingest requests no longer read public keys off disk per request.
Config & Schema Cache: /etc configuration overlays, source definitions, and JSON descriptors are cached in RAM on first access.
Connection Pooling: SQL and database sinks now reuse shared connection pools across rule actions rather than acquiring new sockets.
Multi-Row SQL Batching: For relational sinks (PostgreSQL and SQLite), the sink generates multi-row INSERT INTO ... VALUES (...), (...) statements in parameterized chunks instead of emitting one query per record.

Channel Buffer Sizing

We expanded internal actor queue depths from 1,024 to 32,768 records. On a single pinned core, this provides enough buffer headroom to absorb operating system scheduling jitter without propagating backpressure back into the MQTT network loop.

3. Finding the Exact Limits: Hierarchical 1k Peak Search

Rather than testing arbitrary rounded rates, we searched for the exact ceiling of each workload using a hierarchical binary ladder:

10,000 msg/s steps to identify the 10k window.
2,500 msg/s steps to narrow the bracket.
1,000 msg/s steps to find the exact tipping point.

Test Rig (Identical to previous benchmarks)

Host: 12-core x86-64 machine, Docker on WSL2 (cgroup v2).
Engine Container: Pinned to 1 CPU core, 1 GiB RAM, --memory-swap=1g, TOKIO_WORKER_THREADS=1.
Mosquitto Broker: Isolated container on separate cores, with a strict 4,096-message / 1 MiB outgoing queue limit. If the engine falls behind by even a fraction of a second, the broker drops QoS 0 packets immediately.
Load Generator: mqttgen (our standalone Rust publisher) pushing MQTT 3.1.1 QoS 0 across 8 connections from separate cores.
Verification: Exact message-by-message sink validation checking count, unique IDs, per-device aggregates, and zero exceptions.

4. The Results: Exact Certified Ceilings

Here are the verified limits for all five workloads in rekuiper v0.500-beta:

Workload	Scenario	Certified Ceiling	First Failure	Limiting Factor	Single-Core CPU	Anon RAM
W1	Telemetry Filter (1,000 devices)	150,000 msg/s	151,000 msg/s	CPU saturation (99.4%), broker drops 20.5%	94.5%	17.4 MB
W2	Device 10s Windows (1,000 devices)	200,000 msg/s	210,000 msg/s	Generator schedule (engine lossless to 240k)	94.4%	6.7 MB
W3	ESPHome Topics (10,000 topics, `meta(topic)`)	150,000 msg/s	151,000 msg/s	CPU saturation (99.3%), broker drops 5.0%	97.4%	16.6 MB
W4	Vehicle Windows (10,000 VIN wildcard topics)	200,000 msg/s	210,000 msg/s	Generator schedule (engine lossless to 220k)	97.5%	18.1 MB
W5	EV Charger Sessions (`SESSIONWINDOW(10, 2)`)	126,000 msg/s	127,000 msg/s	Session drain lag (16s exceeds 5s stability limit)	86.7%	6.0 MB

5. Workload Deep-Dive: What Broke Where

W1: Telemetry Filter (JSON parsing + condition)

SQL: SELECT id, device, temp, speed * 3.6 AS speed_kmh FROM telem WHERE temp > 21.0
At 150,000 msg/s: 0.00% loss, 94.5% CPU, 17.4 MB RAM, 1.0s drain lag.
At 151,000 msg/s: Single-core CPU hit 99.4%. The network thread could not drain the socket fast enough; Mosquitto's 4,096-message queue overflowed and dropped 20.53% of packets.
Verdict: 150,000 msg/s is the hard physical CPU ceiling for JSON deserialization, arithmetic projection, and filtering on one core.

W2: Per-Device 10-second Windows (1,000 devices)

SQL: SELECT device, count(*) AS n, avg(temp), max(speed) FROM telem GROUP BY device, TUMBLINGWINDOW(ss, 10)
At 200,000 msg/s: 0.00% loss, 94.4% CPU, 6.7 MB RAM, 10.0s drain lag.
At 210,000–240,000 msg/s: The engine processed all data with 0.00% loss, but the external generator fell off schedule. At 250,000 msg/s, the pipeline collapsed.
Verdict: 200,000 msg/s is our certified on-schedule ceiling. Memory remained at a tiny 6.7 MB because aggregations (count, avg, max) update in place without buffering raw rows.

W3: ESPHome Fleet (10,000 distinct topics, plain text)

SQL: SELECT meta(topic) AS topic, self AS state FROM telem
At 150,000 msg/s: 0.00% loss, 97.4% CPU, 16.6 MB RAM. At the end of sending 4.5 million messages, only 15 messages were in transit.
At 151,000 msg/s: CPU reached 99.3%, dropping 5.05% at the broker.
Verdict: 150,000 msg/s is the exact ceiling for routing and extracting MQTT metadata across 10,000 dynamic topics.

W4: Vehicle Wildcard Aggregation (10,000 VIN topics)

SQL: SELECT device, count(*) AS n, avg(speed), max(temp) FROM telem GROUP BY device, TUMBLINGWINDOW(ss, 10)
Ingests across bench/vehicles/+/telemetry.
Sustained 200,000 msg/s with 0.00% loss and 18.1 MB RAM.
Verdict: Certified at 200,000 msg/s on one core.

W5: EV Charger Sessions (`SESSIONWINDOW`)

SQL: SELECT device, count(*) AS n, max(speed) FROM telem GROUP BY device, SESSIONWINDOW(ss, 10, 2)
2,000 chargers opening and closing irregular activity sessions.
Tested in 1,000 msg/s increments:
- 125,000 msg/s: PASS (0.00% loss, 3.0s lag)
- 126,000 msg/s: PASS (0.00% loss, 4.0s lag, 86.7% CPU, 6.0 MB RAM)
- 127,000 msg/s: FAIL (session close lag spiked to 16.0s, exceeding our 5.0s stability limit).
Verdict: Exact certified limit is 126,000 msg/s.

6. Comparison with Other Engines

Here is the updated head-to-head comparison on the common 5k–100k ladder:

Highest Verified Loss-Free Ingest Rate

Workload	rekuiper 0.500	eKuiper 2.4.1	Telegraf 1.40.0	Redpanda Connect 4.109.0
W1: Telemetry filter	150k certified	20k	50k (backlog)	20k
W2: Device windows	200k certified	20k	Lost 6–27%	5k
W3: ESPHome topics	150k certified	20k	50k (backlog)	20k
W4: Vehicle windows	200k certified	20k	Inconsistent	5k
W5: Charger sessions	126k certified	20k	Unsupported	Unsupported

Memory at 20,000 msg/s (Engine Anonymous RAM)

Workload	rekuiper 0.500	eKuiper 2.4.1	Telegraf 1.40.0	Redpanda Connect 4.109.0
W1: Telemetry filter	4.4 MB	15 MB	92 MB	72 MB
W2: Device windows	6.4 MB	536 MB	52 MB (lossy)	1,012 MB (crashed)
W3: ESPHome topics	4.5 MB	43 MB	85 MB	68 MB
W4: Vehicle windows	10.2 MB	886 MB	94 MB (lossy)	993 MB (crashed)
W5: Charger sessions	7.3 MB	832 MB	Unsupported	Unsupported

At 20k msg/s on 10,000 vehicle windows, engines that buffer raw rows in RAM consume 886 MB to 1 GB, risking kernel OOM kills on edge hardware. rekuiper maintains 10.2 MB by computing aggregates incrementally in fixed-size accumulators.

7. Real Sustained Score vs. Fake Buffer Backlog

One crucial lesson from this benchmark audit: eventual delivery is not throughput.

If an engine accepts 200,000 msg/s for 30 seconds by buffering everything into a huge internal queue, and then spends the next 45 seconds after the publisher stops draining that backlog, that is not a 200k engine. That is an engine surviving on buffer mercy.

In our benchmark harness:

The publisher and broker queues are strictly bounded (Mosquitto queue capped at 4,096 messages).
We record the upstream source gap at the exact millisecond publishing finishes.
If more than 4,096 messages are backlogged at send-end, or if post-send drain takes longer than 5 seconds, the trial is marked as a failure, even if every single message is eventually written to disk.

When we claim 150,000 msg/s on W1 and W3, it means the engine processed all 4.5 million messages in real-time with an end-of-send backlog of 15 messages and a 1.0s drain time.

Trying It Out

rekuiper is free and open source under MIT / Apache-2.0:

GitHub Repository: github.com/ankur-paan/rekuiper
Prebuilt Binaries: Available for Linux (x86_64), macOS (Intel & Apple Silicon), and Windows under Releases v0.500-beta.
Docker:

  docker run -d --name rekuiper \
    -p 9081:9081 -p 20499:20499 \
    -e KUIPER__BASIC__CONSOLELOG=true \
    ankurkrp/rekuiper:0.500-beta

All raw evidence files, harness scripts (mqttgen, iotrunner), and reproduction instructions are published in test/benchmark/iiot-mqtt/.

At the edge, the number that matters is memory - not throughput (specially in Ramageddon)

Ankur Kumar Pandey — Sun, 13 Sep 2026 22:43:55 +0000

We rebuilt LF Edge eKuiper in Rust and ran it against eKuiper, Telegraf and Redpanda Connect on five real MQTT workloads — one core, 1 GB of memory, and output checked message-by-message. The most important result wasn't speed.

I-Dacs Labs Engineering · ~16 min read

Most stream-processing benchmarks you'll read optimize for one number: peak throughput on a big server. That number is close to useless for the place these engines actually run — an industrial gateway, an ESPHome hub, a vehicle head-unit, an EV charger. There, you get one or two CPU cores and a few hundred megabytes of free memory, your input arrives over MQTT, and your traffic is bursty in the worst way: fleets reconnect together, chargers start sessions together, devices flush buffered readings all at once after an outage.

In that world two questions decide whether your pipeline survives, and neither is peak throughput:

Does the engine keep up on a single core?
Does its memory stay bounded when traffic grows?

We built a stream engine called rekuiper to answer "yes" to both, and then we built a benchmark honest enough to tell us if we'd actually managed it. This post is about the benchmark as much as the engine, because the benchmark taught us more than we expected — including a correctness bug in our own code that a throughput-only test would have rewarded as "fast."

The headline: across five MQTT workloads shaped like real deployments, rekuiper produced complete, correct output at 100,000 messages per second on one core in every workload — the top of our tested range, so we never found its ceiling. But the result we care about most isn't that. It's that on the windowed workloads, rekuiper's memory stayed between 5 and 10 MB while the Go-based engines climbed to half a gigabyte to a full gigabyte, or failed. That gap is the whole point, and it comes from design, not from the language.

What rekuiper is

rekuiper is a stream-processing engine written in Rust that reimplements the surface of LF Edge eKuiper: its REST API, its SQL dialect, its stream and rule definitions, and its kuiper command-line interface. The goal was boring on purpose — existing eKuiper rules, the eKuiper Manager web UI, and deployment tooling should keep working — so that "switch the engine" isn't also "rewrite everything."

Concretely, the compatibility surface covers eKuiper's REST API (98 paths and 140 operations, checked black-box against eKuiper's own OpenAPI description), the SQL dialect including JSON paths, CASE, array indexing and unnest, and eKuiper's stream option names (DATASOURCE, FORMAT, CONF_KEY, SCHEMAID, TIMESTAMP, and so on). If you know eKuiper, you already know rekuiper.

What's different is underneath, and it's built around one principle: memory stays bounded under load. Three design choices carry that, and each one shows up later in the numbers.

Three design choices that keep memory flat

Bounded queues with real backpressure

Sources publish records into an in-process stream bus with bounded per-subscriber queues — 4,096 records each. Admission is reserve-then-commit: a batch first reserves capacity in every subscriber's queue, and only then commits. So a batch is either delivered to all subscribers or rejected outright, never half-delivered, and a slow rule pushes back on its source instead of quietly dropping data. Each rule runs as its own task, and its output drains through a bounded sink queue (default 10,000) served by a dedicated sink worker.

The MQTT source uses the rumqttc client, and when a single network read surfaces several publishes, the source admits everything already buffered as one batch of up to 1,024 records. That avoids a per-message wakeup without ever waiting around for more data — you pay one scheduling cost for a burst instead of one per message. This batch-admission trick is a big part of why rekuiper uses roughly half the CPU per message of the Go engines on the simple workloads.

Incremental window aggregation: O(groups), not O(messages)

This is the important one. When you compute GROUP BY device, TUMBLINGWINDOW(ss, 10) with count, avg, max and friends, the naive way is to buffer every row that falls in the window and aggregate at the trigger. Memory then grows with traffic — messages per window — which is exactly the thing that explodes when a fleet reconnects.

rekuiper instead keeps one accumulator per group per aggregate and never stores the rows. Window memory becomes a function of the number of devices, not the number of messages. For the common edge shape — group columns, plain columns, and count/sum/avg/min/max over simple expressions — this incremental evaluator does the whole job. Statements that genuinely need the rows (collect(), joins, some HAVING) fall back to a buffered evaluator, and a unit test checks the two produce identical output on mixed data.

For a fleet, this is the difference between memory that scales with how many vehicles you have and memory that scales with how fast they're all talking at once. Only one of those is safe on a 1 GB box.

An offline sink cache that spills instead of dropping

For intermittent uplinks — a vehicle in a tunnel, a remote site on flaky cellular — a sink can enable a cache using eKuiper's own options (enableCache, memoryCacheThreshold, maxDiskCache, and the rest). Records whose send fails recoverably are queued FIFO: in memory up to a threshold, then in disk pages, and only when the disk budget is exhausted are the oldest records dropped — and counted, not silently lost. The MQTT sink holds one persistent connection per action and reports disconnection, so an outage is detected and cached rather than quietly discarded. (The cache is covered by an integration test but isn't part of the performance numbers here.)

The benchmark that doesn't lie to you

Here's the uncomfortable truth about a lot of edge stream-processing comparisons: they measure throughput at the point the engine acknowledges ingest, or they count output records without checking that the records are correct. Both can hide loss and duplication completely. An engine that drops 15% of your data can look fast if you never verify what came out the other end.

So we built the benchmark around exact output verification, and gave every engine the same cramped room to work in.

Equal, realistic limits. Every engine runs in a container pinned to one CPU core with 1 GB of memory and no swap (--cpuset-cpus=2 --cpus=1 --memory=1g --memory-swap=1g). A separate Mosquitto broker gets its own cores and generous queue limits, so the broker is never the bottleneck. An open-loop Rust load generator (mqttgen, standard library only, MQTT 3.1.1, QoS 0) feeds every engine from the same schedule, and a step only counts if the generator actually stayed on schedule.

Four engines. rekuiper v0.425-beta, eKuiper 2.4.1, Telegraf 1.40.0, and Redpanda Connect 4.109.0 (formerly Benthos). We deliberately excluded Apache Flink: neither Flink 2.x nor Apache Bahir ships an MQTT connector, so testing Flink would have meant a custom source or a Kafka bridge — changing the very ingest path under test. Rather than benchmark a different pipeline and call it Flink, we left it out and said so.

Five workloads shaped like real deployments:

W1 — telemetry filter. 1,000 devices, one topic, a simple WHERE temp > 21.0 with a unit conversion. Stateless.
W2 — per-device windows. 1,000 devices, 10-second tumbling windows with count/avg/max. Stateful.
W3 — ESPHome states. 10,000 plain-text topics via wildcard, using FORMAT="binary" and meta(topic) to carry the topic through. Stateless but wide.
W4 — vehicle windows. 10,000 topics (one per VIN), 10-second tumbling windows. Stateful and wide — the hardest memory test.
W5 — EV charger sessions. 2,000 topics, SESSIONWINDOW(ss, 10, 2). Neither Telegraf nor Redpanda Connect has a session window, so they can't express it at all.

Proofs, not vibes. For each engine, workload and rate (5k, 20k, 50k, 100k msg/s), we warm up until the subscription is provably live, send for 30 seconds on a fixed schedule, drain until the sink file stops growing, then verify the output exactly:

W1: the count of unique message IDs carrying the run tag must equal the closed-form expected filtered count, with no duplicates.
W2, W4, W5: the sum of per-device counts across all output windows must equal the messages sent, and every device must appear.
W3: output rows must equal messages sent, and all 10,000 topics must appear.

A step is complete only when its proof holds. "Loss" is the relative shortfall against the proof. This is the part that makes the numbers trustworthy — and, as you'll see, it's the part that caught our own bug.

Results

Nobody else finished the range

Highest tested rate with complete, correct output:

Workload	rekuiper	eKuiper 2.4.1	Telegraf 1.40.0	Redpanda Connect 4.109.0
W1 telemetry filter	≥ 100,000	20,000	50,000 (lag 10 s)	20,000
W2 per-device windows	≥ 100,000	20,000	none	5,000
W3 ESPHome states	≥ 100,000	20,000	50,000 (lag 5 s)	20,000
W4 vehicle windows	≥ 100,000	20,000	50,000 only	5,000
W5 charger sessions	≥ 100,000	20,000	not supported	not supported

rekuiper completed all 20 steps. Because 100,000 msg/s was the top of the range, we never reached its limit — at 100k on the wide ESPHome workload it used 96.6% of the core, and the windowed workloads used 78–85%, so there's headroom left. eKuiper was solid and complete up to 20,000 msg/s across the board. Telegraf managed 50,000 on two stateless workloads but never produced complete per-device windows at any rate. Redpanda Connect reached 20,000 on stateless workloads and 5,000 on windows.

The memory gap

This is the result we'd frame and put on the wall. Peak engine heap (cgroup anonymous memory) at 20,000 msg/s, the highest rate every engine could still be compared at:

Workload	rekuiper	eKuiper	Telegraf	Redpanda Connect
W1	4.7	15.3	91.6	71.5
W2	5.4	535.9	51.6 †	1,012.3 †
W3	4.8	43.2	84.9	67.7
W4	10.0	886.2	94.0 †	992.9 †
W5	5.9	831.7	n/a	n/a

(† marks a step whose correctness proof failed — the memory figure is real, but the engine wasn't producing complete output.)

On the windowed workloads (W2, W4, W5), eKuiper's heap ran to 536–886 MB and Redpanda Connect's system_window pattern — which holds every message of a window before aggregating — hit the 1 GB ceiling. rekuiper stayed at 5–10 MB at every rate on every workload. Two orders of magnitude, on the exact workload edge fleets generate.

CPU: roughly half

At 20,000 msg/s, rekuiper used 44–49% of one core. eKuiper used 86–99%, and the two Go pipeline tools were similar or worse (on the steps where they were even producing correct output). About half the CPU per message, which on a shared single-core box is the difference between comfortable headroom and being one traffic spike away from falling behind.

Where the difference actually comes from

It would be easy, and wrong, to write this up as "Rust beats Go." The language helps, but the CPU difference on the stateless workloads is roughly 2×, not 10×, because MQTT receive, JSON decode and file writing dominate for everyone. The interesting gaps are structural.

Window memory is a design choice, not a language feature. eKuiper's windowed memory grows with message rate — about 125 MB at 5,000 msg/s, 536–886 MB at 20,000 — and hits the 1 GB limit at 50,000, where output loss immediately follows. Redpanda Connect's documented windowing buffers the whole window and reaches the limit from 20,000 msg/s. rekuiper's incremental evaluator keeps one accumulator per device, so heap is a function of fleet size, not traffic. Any of these engines could adopt the same approach; the point is that it's the approach, not the runtime, that matters here.

The loss mechanism is the broker, honestly reported. When an engine falls behind, its MQTT subscription backs up and the broker drops QoS 0 messages for that slow subscriber. This is visible directly in the input counters — for instance, eKuiper received only 1.23 of 3.0 million messages on W1 at 100,000 msg/s. Under QoS 1 the same overload would surface as backpressure on the publishers instead of loss. We report QoS 0 because it's the common, cheap edge default, and because it makes overload measurable rather than hidden.

The bug our own benchmark caught

Here's the part we could have quietly left out, and won't.

An earlier run of this exact harness, on a previous rekuiper build, showed about 15% "loss" on W2 at every rate, and 100% loss with 820 MB of memory at 100,000 msg/s. It looked like overload. It wasn't — it was a correctness defect in our window evaluation.

Our time-window trigger was collapsing the whole window into a single aggregate: it ignored GROUP BY partitioning (emitting one row per window, with group values taken from the first record), ignored WHERE, and buffered and cloned every row on the way. The reason it produced a suspiciously constant shortfall was subtle: the warm-up device's row was absorbing the first window of measured data every time.

Our unit tests didn't catch it, because they aggregated a single group — exactly the case the bug handled correctly. Only the exact per-device proof in the benchmark exposed it. We fixed it (that fix is the incremental evaluator described above) before the final measurements.

We're telling you this because it's the strongest argument in the whole paper for verifying output content: a throughput-only benchmark, or one that counts output rows without checking their identity, would have looked at that defective build and reported it as fast and lean. The bug reduced work by skipping grouping and filtering. Speed without a correctness proof is not a measurement; it's a guess with a stopwatch.

A "neutral" harness detail that reordered the results

One more methodology lesson, because it surprised us.

In an earlier comparison, the output sink file lived on a Windows-drive bind mount, where every write system call is expensive. Telegraf's file output, by default, issues one unbuffered write per metric; Redpanda Connect writes each message individually. Both were bound by the sink, not their own logic — flat CPU around 40–47% while losing up to 89% of messages — purely because of where the file lived. eKuiper was affected too, though less. rekuiper batches its file writes, so it barely noticed.

Moving the sink to the VM's local ext4 filesystem changed the standings substantially. eKuiper W1 at 20,000 msg/s went from 1.7% loss to complete; Telegraf W1 at 20,000 went from 37% loss to complete. Same engines, same rates, same rules — different disk. We kept the superseded runs in the artifact and marked them as such, and the lesson is now a rule we'd apply to any stream-processor benchmark: state where your sink writes and how often it issues system calls, because that detail can quietly decide your rankings.

(There's an honest loose end here too: Telegraf lost a near-constant 9.4% on the windowed workloads at low rates even with a grace period, yet was complete at 50,000 on W4. We didn't find the cause. The configuration is published so someone else can.)

What this doesn't prove

We build rekuiper, so treat the framing with the skepticism it deserves — and here's what to hold against it:

One host, one repetition. The whole run was a single laptop under Windows 11 and WSL2, one repetition per cell. Host-health snapshots flag several runs as noisy. The gaps are large relative to that noise, and an earlier run showed the same qualitative pattern, but repeated runs on a dedicated Linux host would be stronger.
A coarse rate ladder. "20,000" means an engine passed 20,000 and failed at 50,000; the true limit is somewhere in between. rekuiper's ceiling wasn't measured at all.
Defaults, mostly. eKuiper ran with default rule options; a partial run with larger buffers showed a similar pattern but wasn't repeated. Redpanda Connect used its documented windowing pattern — other designs might do better.
QoS 0 only. No QoS 1/2, TLS, broker reconnect storms, event-time or out-of-order windows, joins, or non-MQTT connectors. rekuiper's MQTT path is its stable, benchmarked path; its other connectors are not yet considered stable.

None of that changes the central, two-order-of-magnitude memory result, but you should know exactly where the edges of the claim are.

Try it, and break it

Everything here is reproducible. The engine, the orchestrator, the load generator, every configuration, and the raw per-step evidence (per-second CPU and memory, generator reports, input counters, host health, image IDs) are published at tag v0.425-beta:

git clone https://github.com/ankur-paan/rekuiper.git
cd rekuiper
# Method, configs and commands:
#   test/benchmark/iiot-mqtt/README.md

A full run — four engines, five workloads, four rates — takes about 1 hour 45 minutes and needs Linux or WSL2 with Docker (cgroup v2), a Rust toolchain, and at least 12 logical CPUs.

If you run IIoT gateways, ESPHome fleets, vehicle telemetry, or EV chargers, the most useful thing you can do with this is try to break it on your own hardware and your own rules — especially ARM, and especially with buffer settings tuned for your traffic. We'd genuinely rather hear where it falls over than where it wins.

Because at the edge, the engine that survives a Monday-morning reconnect storm isn't the one with the biggest throughput number. It's the one whose memory you can still predict when ten thousand devices all start talking at once.

👉 GitHub: https://github.com/ankur-paan/rekuiper

rekuiper v0.425-beta is dual-licensed MIT / Apache-2.0.

We rewrote LF Edge eKuiper in Rust: 425k eps, 8MB RAM, 13ms boot (vs Flink, Go eKuiper & Benthos)

Ankur Kumar Pandey — Thu, 10 Sep 2026 03:30:28 +0000

Over at I-Dacs Labs, we run high-throughput telemetry pipelines on edge devices (Raspberry Pis, Advantech gateways, and embedded x86/ARM boxes). We've been using LF Edge eKuiper for local stream processing (SQL filtering, sliding windows, and MQTT/Kafka sinks), but kept hitting the classic edge computing wall:

JVM engines (Apache Flink): Incredible throughput, but require >1 GB RAM and take 20+ seconds to boot. Unusable on small industrial hardware.
Go engines (Upstream eKuiper, Benthos, Telegraf): Much lighter, but continuous Stop-The-World GC sweeps introduced tail latency jitter. Worse, under burst sensor loads (10k–100k events/sec), Go channel buffer saturation led to silent packet loss. We decided to rewrite the entire engine in pure Rust: rekuiper (v0.421-beta, dual licensed under MIT / Apache-2.0). --- ### What We Built
Core Architecture: Lock-free stream bus (StreamBus), Tokio async actors for rule execution, and bounded actor queues for sinks with zero runtime GC pauses.
100% Drop-In Parity: Fully compatible with the existing eKuiper Manager Web UI, OpenAPI 3.0 schemas, and standard streaming SQL. Zero scaffolded stubs across all 98 REST endpoints.
Footprint: 9.60 MB stripped static binary, ~6 – 8.2 MB idle RAM consumption.

- Sub-15ms Cold Boot: 12.5 – 14.5 ms internal daemon bootstrap; 123 ms end-to-end process-spawn-to-ready.

Empirical Head-to-Head Benchmarks (500,000 Records)

Rather than hand-waving estimates, we ran all engines head-to-head on the exact same Linux machine (WSL2 / Ubuntu x86_64) using an identical 500,000-record telemetry workload:
Pipeline: Parse 500k JSON events → Compute formula (temp * 1.8 + 32) → Filter (temp > 20.0) → Project (id, temp_f) → Sink

Engine	Runtime	500k Elapsed	Throughput	Data Drops	Memory
rekuiper (0.421)	Pure Rust	1.176 s	425,308 eps	0 (0.0%)	~8 MB
Apache Flink	Java / JVM	2.144 s	233,209 eps	0 (0.0%)	~1,022 MB
Telegraf	Go	8.194 s	61,019 eps	0 (0.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 (0.0%)	~38 MB

Key Observations:

Channel Saturation in Go: Under sustained 500k burst ingestion, upstream Go eKuiper dropped 72,921 records (14.6% data loss) due to channel saturation (buffer full, drop message). rekuiper processed all 500,000 events with 0 drops in 1.176s (9.6x faster).
vs Apache Flink: Flink’s execution graph is fast (233k eps), but the JobManager + TaskManager JVM consumed over 1 GB of RAM. rekuiper beats it in single-core throughput while consuming 125x less RAM (< 8.2 MB).

3. Cold Boot Time: `rekuiper` boots internally in ~13 ms (123 ms OS spawn to socket ready), compared to 1.2s for Go eKuiper and 20s for Apache Flink.

Reproduce It in 2 Minutes

All reproduction scripts and Docker configs are in the repository. Anyone can run the whole suite:

git clone https://github.com/ankur-paan/rekuiper.git
cd rekuiper
./test/benchmark/run_all.sh