cloudparts

eKuiper

A small stream processing engine for edge gateways: SQL rules filter, window and aggregate sensor data from MQTT, EdgeX and other sources before it leaves the site.

LF Edge · At-Large
What it is
Stream processing
Used for
IoT device messaging
Type
Open source
Made by
LF Edge (Linux Foundation), started at EMQ
Foundation
LF Edge, at-large. Part of the Linux Foundation
License
Apache 2.0
Facts checked
28 October 2026
Website Source code

What it is

Sending every raw sensor reading to the cloud costs bandwidth and adds latency, and a gateway beside the machines usually has a few hundred megabytes of memory, not a Flink cluster. eKuiper is a single Go binary for that gateway: the core server package is about 4.5 MB and uses about 10 MB of memory, and it runs on x86 and Arm, 32- and 64-bit, on Linux distributions including OpenWrt, on macOS and in Docker. Its own README calls it a streaming framework “similar to Apache Flink” at the edge.

You first declare a stream, which works like a table definition: a schema, a format such as JSON, and a source, for example an MQTT topic filter. A rule is then a SQL query over streams, or a graph of nodes in the style of Node-RED, plus a list of actions that say where results go. The SQL has more than 60 functions, joins with tables and lookups in databases, and four time windows plus a count window. Built-in sources include MQTT, EdgeX, Neuron, HTTP, files, Redis and WebSocket, with plug-ins for SQL databases, Kafka, ZeroMQ and video; sinks add InfluxDB, IoTDB and others. Sources, sinks and functions can be extended in Go or Python, including functions that run ONNX models. Rules are managed through a CLI, a REST API, a web dashboard or Kubernetes config maps.

State such as an open window lives in memory by default. Setting a rule’s qos to 1 or 2 turns on checkpointing to storage, giving at-least-once or exactly-once effects on that state after a crash, provided the source can rewind; the sink can still receive duplicates. eKuiper is the rules engine the EdgeX Foundry docs list among their supporting services. EMQ, which created it, open-sourced it in 2019 and donated it to LF Edge in 2021, where it sits at the At-Large stage; the 2.x series began in October 2024, and 2.4.0 followed in May 2026.

Why teams pick it

  • Very small: about 4.5 MB on disk and 10 MB of memory, so it fits on industrial gateways, routers and Raspberry Pi-class boards
  • Rules are SQL with windows, joins and 60+ functions, so filtering and aggregating at the edge doesn’t need custom code
  • Ready-made connectors for MQTT, EdgeX and the Neuron industrial gateway, with plug-ins for Kafka, SQL databases and time-series stores
  • Rules can be added, changed and stopped at runtime through a REST API, which suits gateways managed remotely

Watch out for

  • One process on one machine: there is no cluster or partitioning, so it doesn’t scale out like Flink or Kafka Streams
  • State is in memory unless checkpointing is turned on, and even then exactly once only covers internal state, not what the sinks receive
  • An At-Large LF Edge project, the entry stage, and closely tied to EMQ, which integrates it with its own EMQX, Neuron and NanoMQ products
  • Many connectors, including Kafka and SQL, are plug-ins that have to be built or installed separately

Alternatives

What all stream processing have in common →Compare side by side →
Apache FlinkOpen sourceThe most widely used open-source engine for stateful stream processing: keyed state, event time and exactly-once recovery from checkpoints.Kafka StreamsOpen sourceA Java library, part of Apache Kafka, that turns your own application into a stateful stream processor with no cluster of its own.Redpanda ConnectRenamedOpen sourceFormerly Benthos: one Go binary that runs a YAML pipeline of inputs, processors and outputs, with at-least-once delivery and no disk state of its own.ArroyoOpen sourceA stream processing engine in Rust: you write the pipeline as SQL, and it keeps windows and joins running with checkpointed state.BytewaxOpen sourceA Python stream processing framework on a Rust engine built on Timely Dataflow; its company wound down in 2025 and the last release is from November 2024.Cloudflare Basin PipelinesRenamedCommercialCloudflare’s managed streaming ingestion service, called Cloudflare Pipelines until October 2026, that takes events over HTTP or a Workers binding, transforms them with SQL and writes them to R2 as Apache Iceberg tables, Parquet or JSON.DenormalizedArchivedOpen sourceAn embeddable stream processing library in Rust, with Python bindings, built on Apache DataFusion. Abandoned since December 2024 at version 0.0.13.FelderaOpen sourceAn incremental view maintenance engine in Rust: you write SQL tables and views, and it keeps every view up to date by processing only the changes, based on the award-winning DBSP theory.KamuExperimentalCommercialA command-line tool and server that keep datasets as tamper-evident event ledgers and build derived datasets from them with streaming SQL, run by plug-in engines such as Flink and DataFusion.ksqlDBCommercialConfluent’s SQL server for Kafka: queries that run forever, turning topics into new topics and into tables you can look up.PathwayCommercialA Python framework for streaming ETL and live RAG pipelines: you write table transformations in Python, and a Rust engine built on Differential Dataflow keeps the results up to date.Quix StreamsOpen sourceA pure-Python library for stateful stream processing on Kafka: a pandas-like Streaming DataFrame, RocksDB state backed up to Kafka, and no cluster of its own.RisingWaveOpen sourceA streaming database in Rust that speaks the PostgreSQL protocol: you write materialized views in SQL, and it keeps them up to date as events arrive, with all state in object storage.StreamFusionOpen sourceAn open-source accelerator for Apache Flink SQL: Flink still plans and coordinates the job, while the operators it can reproduce exactly run natively in Rust on Arrow and DataFusion.StreamlingCommercialGoldsky’s young Rust pipeline runtime: YAML pipelines of stateless SQL, TypeScript and plugin steps on Arrow, from Kafka or files into Postgres, ClickHouse or webhooks.Timely DataflowOpen sourceA Rust library for data-parallel dataflow with logical timestamps, loops and exact progress tracking; the engine underneath Materialize.

How it fits with other technologies

A rule: every 5 seconds, publish the averages if it got hot · json

{
  "sql": "SELECT count(*), avg(temperature) as avg_temp, max(humidity) as max_hum from demo group by TUMBLINGWINDOW(ss, 5) HAVING avg_temp > 30;",
  "actions": [{
    "mqtt": {
      "server": "tcp://127.0.0.1:1883",
      "topic": "result/myRule",
      "sendSingle": true
    }
  }]
}

See it in a real stack

No architecture uses eKuiper yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2026

EMQ, the company behind the EMQX MQTT broker, wrote Kuiper for places such as production lines, connected vehicles and wind farms, where processing device data on the gateway cuts latency, bandwidth and storage costs. Stream processors such as Flink were built for clusters, so Kuiper was a small Go engine with a SQL rule language. EMQ open-sourced it in 2019, and its first release, 0.0.2, came that October with SELECT … FROM … WHERE, functions and a command-line tool.

Integration with EdgeX Foundry came early: version 0.3.2, in April 2020, was the release that shipped with EdgeX’s Geneva release, and eKuiper went on to become the rules engine in the EdgeX documentation. Version 1.0.0 followed in October 2020. In April 2021 the project was put to the LF Edge Technical Advisory Council for the At-Large stage, and it was donated to LF Edge that year under the name LF Edge eKuiper.

Releases came roughly every quarter after that. Version 2.0 in October 2024 reworked connections so several rules share one, split sources and sinks into separately measured steps, added an ONNX function for running models, and added OpenTelemetry tracing.

Why it’s built this way

SQL as the rule language
Plant engineers and integrators already knew SQL, and a declarative query can be added or changed on a running gateway without compiling anything.
A single small binary in Go
Edge gateways have little memory and many CPU architectures; a static Go binary of a few megabytes runs on all of them without a JVM.
Plug-ins for everything beyond the basics
Keeping Kafka, SQL and video connectors out of the core keeps the default build small for devices that only need MQTT.

Timeline

  1. 2019

    EMQ open-sources Kuiper; first release, 0.0.2, in October

  2. 2020

    0.3.2 ships with EdgeX Geneva in April; 1.0.0 in October

  3. 2021

    Put to the LF Edge TAC in April and donated to LF Edge as eKuiper

  4. 2024

    2.0.0 in October: shared connections, ONNX inference, tracing

  5. 2026

    2.4.0 in May; 2.5 in alpha by October

Sources7 · facts checked 28 October 2026

Improve this page on GitHub