Eclipse ZenohIncubating

A pub/sub, query and storage protocol that runs peer to peer or through routers, from microcontrollers to the cloud; also a ROS 2 middleware.

What it is: IoT device messaging
Used for: Pub/sub
Type: Open source
Made by: Eclipse Foundation; developed mainly by ZettaScale Technology
License: Dual-licensed: EPL 2.0 or Apache 2.0
Status: Incubating. Still an incubating Eclipse Foundation project.
Facts checked: 6 October 2026

What it is

Zenoh names data by key, a path such as myhome/kitchen/temp, and offers three things on keys. Publishers put values that every matching subscriber receives. A get sends a query to every queryable whose key expression matches, and wildcards such as myhome/** work on both sides. Storages are queryables that remember the latest value for each key they cover. Applications link a library: the reference implementation is in Rust, with bindings for C, C++, Python, Kotlin, Java, Go and TypeScript, plus zenoh-pico, a separate pure-C implementation for microcontrollers. In peer mode, the default, applications find each other on the local network by multicast scouting and talk directly, with no broker. In client mode a constrained device keeps a single session to a router, zenohd, and routers link sites together. Routers load plugins: a storage manager with backends such as memory or S3, a REST API on port 8000, and an MQTT plugin that acts as a broker for MQTT 3 and 5 clients.

Zenoh is an incubating Eclipse Foundation project, dual-licensed under EPL 2.0 and Apache 2.0, and free to use. Its main developer and sponsor is ZettaScale Technology, founded in 2022, which sells support and a commercial Zetta Platform. Zenoh 1.0 shipped in October 2024 with a stabilised API, and its ROS 2 middleware, rmw_zenoh, became a Tier 1 option alongside the DDS implementations in ROS 2 Kilted Kaiju (May 2025).

Why teams pick it

Pub/sub and queries on the same keys, so a dashboard can ask for the latest values and then subscribe to changes with one library
Peer to peer on a local network: two devices next to each other talk directly instead of through a remote broker
Scales down to microcontrollers with zenoh-pico; the project quotes a wire overhead of 4 to 6 bytes
A Tier 1 ROS 2 middleware since Kilted Kaiju, and plugins bridge MQTT and DDS systems into the same network

Watch out for

A much smaller ecosystem than MQTT or Kafka: one main implementation, mostly from one company, and no cloud provider offers it as a managed service
Storages keep the latest value per key, not a replayable log; history needs a backend such as a database
Its own protocol: MQTT clients and DDS applications only join through plugins or bridges
The API changed substantially before 1.0, with a migration guide from 0.11, and the project is still incubating at Eclipse
With rmw_zenoh, ROS 2 nodes need a Zenoh router running to discover each other, because multicast discovery is off by default

Alternatives

What all iot device messaging have in common →

AWS IoT CoreAWSAWS’s managed MQTT broker for devices, with per-device certificates, a SQL rules engine that routes messages into AWS services, and cloud-side device state.

Azure IoT HubAzureAzure’s device gateway: a registry of device identities, telemetry into an Event Hubs-compatible stream, and device twins, direct methods and cloud-to-device messages, sold in fixed-price units with a daily message quota.

EMQXCommercialAn Erlang MQTT broker built for very large device fleets, with a SQL rule engine, now under the Business Source License.

HiveMQCommercialA Java MQTT broker built for clusters, sold as self-managed software or as HiveMQ Cloud, with an open-source single-node edition.

MQTTOpen sourceThe small publish/subscribe protocol most IoT devices use to talk to a broker, standardised by OASIS and ISO.

How it fits with other technologies

What Eclipse Zenoh uses

Eclipse Zenohkeeps stored keys, through a backend, inAmazon S3Object storage

What uses Eclipse Zenoh

MQTTis bridged, through a plugin, intoEclipse ZenohIoT device messaging

Publish readings, then query the latest value from a router’s storage · python

# pip install eclipse-zenoh
# router with a memory storage on myhome/**:  zenohd -c zenoh-myhome.json5  (see below)
import random, time
import zenoh

with zenoh.open(zenoh.Config()) as session:  # peer mode: finds others by multicast
    session.declare_subscriber(
        "myhome/**", lambda s: print("live", s.key_expr, s.payload.to_string())
    )

    pub = session.declare_publisher("myhome/kitchen/temp")
    for _ in range(5):
        pub.put(str(random.randint(15, 30)))
        time.sleep(1)

    # a get is answered by whatever queryable matches: here, the router’s storage
    for reply in session.get("myhome/kitchen/temp"):
        print("stored", reply.ok.key_expr, reply.ok.payload.to_string())

A router that stores what it sees#

The zenohd configuration behind the snippet. The storage subscribes to myhome/** and answers queries for it; the REST plugin lets you read the same data with curl http://localhost:8000/myhome/**.

json

{
  "plugins": {
    "rest": { "http_port": 8000 },
    "storage_manager": {
      "storages": {
        "myhome": {
          "key_expr": "myhome/**",
          "volume": { "id": "memory" }
        }
      }
    }
  }
}

Zenoh or MQTT?#

Both carry small messages from devices on topics or keys. They differ in topology, in what they store, and in how many implementations exist.

	Zenoh	MQTT
Topology	Peer to peer, client to router, or a mix, chosen per application	Always client to broker
Operations	Publish, subscribe, query (`get`), queryables and storages	Publish and subscribe; 5.0 adds request/response properties
What it stores	Latest value per key in storages, with pluggable backends	One retained message per topic, plus queues for persistent sessions
Small devices	zenoh-pico, a pure-C implementation	Designed for small footprints; MQTT-SN for networks without TCP/IP
Implementations	One main open-source implementation; the protocol spec is published by the project	OASIS and ISO standard, with many brokers and client libraries
Managed cloud services	None from the big clouds	AWS IoT Core, Azure IoT Hub and Event Grid

See it in a real stack

No architecture uses Eclipse Zenoh yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2020–2025

Angelo Corsaro, then CTO of PrismTech and co-chair of the OMG group behind the Data Distribution Service (DDS) standard, worked on very large distributed systems for military, aerospace and smart-city projects. He saw no single protocol that covered them end to end. DDS handled pub/sub well but, in his view, could not scale up to the internet or down to microcontrollers; CoAP was client/server; and MQTT made two devices on the same network talk through a remote broker. Nothing let you query data at rest without knowing where it lived.

Zenoh set out to cover all of it with one protocol: pub/sub, geo-distributed queries and storage, from microcontroller to data centre, in any topology. In 2020 the team brought it to the Eclipse Foundation and rewrote the router in Rust; the first Rust-based release, Aithusa, came out in October 2020 with DDS and ROS 2 integration. ZettaScale was founded in 2022 to develop it commercially.

Its biggest step came from robotics. In September 2023 the ROS 2 core team published a report choosing a non-DDS middleware to build a new RMW on, which became rmw_zenoh. Zenoh 1.0 followed in October 2024, and rmw_zenoh became Tier 1 in ROS 2 Kilted Kaiju in May 2025.

Why it’s built this way

Peer to peer first, routers optional: Sending traffic between two machines on the same network through a cloud broker adds latency and a single point of failure. Peers discover each other by multicast and talk directly; routers are added only where sessions must be shared or networks joined.
Queries and storage in the protocol: Pub/sub alone only covers data in motion. Making queryables and storages first-class means an application can ask for data at rest by key without knowing which database holds it.
A Rust core with a separate C version for microcontrollers: The 2020 rewrite put the router and main library in Rust, with other languages as bindings, while zenoh-pico reimplements the protocol in plain C for devices too small for the Rust stack.

Timeline

2020
Zenoh moves to the Eclipse Foundation; Rust rewrite begins
2020
Aithusa, the first Rust-based release, ships in October
2022
ZettaScale Technology founded in May
2023
ROS 2 core team picks Zenoh for a new non-DDS middleware
2024
Zenoh 1.0 “Firesong” released on 21 October with a stable API
2025
rmw_zenoh becomes Tier 1 in ROS 2 Kilted Kaiju

Sources18 · facts checked 6 October 2026

Improve this page on GitHub