Zenoh: The Protocol That Runs From Microcontroller to Data Center

Most distributed systems end up with a protocol zoo. MQTT for IoT sensors because it's lightweight. Kafka for the data pipeline because it handles volume. REST for microservices because everything speaks HTTP. DDS for robotics because ROS2 requires it. And then a constellation of bridges, adapters, and translation layers to connect all of them — each adding latency, complexity, and another failure point.

Zenoh is the protocol that's trying to eliminate this zoo. It runs the same protocol from a bare-metal microcontroller with 64KB of RAM to a cloud data center, handles pub/sub messaging, geo-distributed queries, and persistent storage in a unified abstraction, and requires no broker for peer-to-peer topologies. One protocol, the full range of distributed systems.

What Zenoh is

Zenoh (pronounced "zeno") is an open-source pub/sub/query protocol designed to unify data in motion, data at rest, and computations across heterogeneous networks. It's developed by ZettaScale Technology, hosted under the Eclipse Foundation, Apache 2.0 licensed, and written in Rust — with official bindings for Python, C, C++, Java, Kotlin, TypeScript, and as of version 1.9.0, Go.

The current stable release is 1.9.x (Longwang), shipped April 2026. The GitHub repository has 4,700+ stars across the main zenoh crate, with active development and a bi-monthly release cadence named after mythological figures.

The name is both a philosophical tribute and an acronym: Zero Endpoint Network Overhead Handover — capturing the goal of eliminating unnecessary overhead at every layer of the stack.

Zenoh was designed by Angelo Corsaro, who co-chaired the OMG Data Distribution Service (DDS) specification group, after seeing the protocol gap in large-scale distributed systems for military, aerospace, and smart-city projects. No single protocol could span the full range: DDS was excellent for robotics and real-time systems but couldn't scale to internet scope or down to microcontrollers. MQTT needed a broker even for two devices on the same local network. Zenoh is the attempt to build what should have existed.

The three primitives

Zenoh's design is built around three composable abstractions that cover most distributed data needs:

Publish/Subscribe

The familiar pub/sub model, but without the broker requirement. Publishers write to key expressions (slash-separated paths like robot/sensor/temp or vehicle/zone1/pressure). Subscribers declare interest in key expressions that can include wildcards (robot/sensor/* or vehicle/**/pressure). Zenoh routes data efficiently between them regardless of network topology — peer-to-peer, brokered, or hybrid.

# Python — publisher
import zenoh
session = zenoh.open(zenoh.Config())
pub = session.declare_publisher("robot/sensor/temp")
pub.put({"value": 42.7, "unit": "celsius"})

# Python — subscriber
sub = session.declare_subscriber("robot/sensor/*", lambda sample:
    print(f"Received: {sample.key_expr} = {sample.payload}")
)

Query/Reply (Queryables)

Where pub/sub handles data in motion, queries handle data at rest. Any Zenoh node can declare itself a Queryable — a handler that responds to queries matching a key expression. This is how Zenoh provides geo-distributed data access: you query fleet/trucks/**/telemetry and Zenoh routes the query to whichever nodes have matching data, collects replies, and returns them. Location transparency for data at rest — you ask for data without knowing or caring where it lives.

Geo-Distributed Storage

Zenoh nodes can declare storage — persistent or in-memory — backed by the filesystem, RocksDB, S3-compatible storage, InfluxDB, or any custom backend via the plugin architecture. Publications to a key expression are automatically stored. Queries retrieve historical data. The storage layer integrates seamlessly with the pub/sub layer — a sleeping subscriber that comes back online can query for missed publications from the nearest storage rather than losing them.

The topology model

This is what makes Zenoh architecturally distinct from MQTT and similar broker-dependent protocols.

Zenoh supports three node roles, composable into arbitrary topologies at runtime:

• Router — a standalone Zenoh daemon (zenohd) that routes messages and provides infrastructure services. Comparable to an MQTT broker but not required for all topologies.
• Peer — a node that communicates directly with other peers without a router, forming mesh or clique topologies for local networks.
• Client — a lightweight node that connects through a router or peer, suitable for constrained devices.

The critical feature: topology is decided at runtime, not hardcoded in the protocol. Two Zenoh peers on the same network communicate directly via multicast discovery and peer-to-peer links. When they need to reach nodes in the cloud, they route through a Zenoh router. When they're embedded devices with 64KB RAM, they run zenoh-pico, the pure C implementation designed for constrained hardware, and connect as clients. Same protocol, same key expressions, same API — no translation layer.

Zenoh 1.9.x (Longwang) introduced Regions — a complete reimagining of the topology model that enables arbitrarily deep network hierarchies. Instead of the traditional three-layer router/peer/client model, you can now design nested subregions, configure custom gateway relationships, and scale to deployments that span multiple geographic regions, each with their own internal topology. This enables large-scale deployments — from edge robotics that connect hubs as clients, to fleet management systems that span continents — without hitting the scaling limits of any single topology type.

Transport layer

Zenoh runs over TCP, UDP, TLS, QUIC, WebSocket, Unix domain sockets, and serial links. Zenoh 1.9.x added QUIC stream multiplexing and mixed reliability support — combining reliable and unreliable streams on the same QUIC connection, which is important for real-time systems where some data (like sensor readings) can be lost while control commands must be delivered reliably.

The transport-agnostic design means Zenoh works over whatever link is available: TCP for cloud, QUIC for low-latency links, UDP multicast for local network discovery, serial for embedded-to-embedded communication.

Zenoh-Pico — for constrained devices

zenoh-pico is the pure C implementation of the Zenoh protocol designed for microcontrollers and constrained devices. It runs on hardware with as little as 64KB of RAM, supports Arduino, Zephyr RTOS, FreeRTOS, and bare metal targets. It implements the same key expressions and API as full Zenoh, meaning a constrained sensor can publish to the same namespace as a cloud service with no translation layer.

Zenoh 1.9.x added a new async executor model to zenoh-pico that reduces resource usage in single-threaded mode while enabling advanced features like auto-reconnection and peer-to-peer mode on constrained hardware. This is the same stack you'd run on a vehicle ECU, an industrial sensor node, or an autonomous robot's embedded controller — all communicating natively with cloud services using the same protocol.

Zenoh and ROS2

One of the most significant production use cases for Zenoh is as the middleware for ROS2 (Robot Operating System 2). ROS2 traditionally uses DDS (Data Distribution Service) as its middleware layer — powerful for robotics but heavyweight for some deployments and difficult to bridge to the broader internet.

rmw_zenoh is an official ROS2 middleware implementation that replaces DDS with Zenoh. This gives ROS2 applications native pub/sub across heterogeneous networks without DDS's discovery overhead, access to Zenoh's storage and query capabilities, and the ability to extend robot communication to the cloud or to constrained edge devices without a separate bridge layer.

The Zenoh team has published benchmarks showing significant CPU and memory efficiency gains for ROS2 workloads: running a Zenoh router with 100 ROS2 nodes (50 publishers, 50 subscribers) on a 4-core 8GB machine shows substantially lower resource consumption than equivalent DDS deployments.

Automotive — Software Defined Vehicles

Automotive is another primary use case. Modern vehicles are increasingly "Software Defined Vehicles" (SDVs) — computers on wheels where electronic control units (ECUs) communicate sensor data, run algorithms, and actuate physical systems. SOME/IP and CAN bus have been the traditional in-vehicle protocols, but they don't extend cleanly to cloud connectivity or over-the-air updates.

Zenoh fits the automotive architecture: ECUs run zenoh-pico as clients to zonal routers, zonal routers communicate with a central vehicle router, and the vehicle router connects to cloud infrastructure. Same protocol, same key expressions, from tire pressure sensor to fleet management backend. The security analysis from Census Labs (March 2025) identified the multi-router hop-by-hop encryption model as worth noting for sensitive deployments — something to understand when designing security-critical automotive architectures.

Language support

The primary implementation is Rust, with all other language bindings wrapping the Rust core (except zenoh-pico which is pure C). Official supported languages:

• Rust — primary implementation, full feature set
• Python — binding via PyO3, suitable for scripting and data science workflows
• C / C++ — for systems programming and embedded use
• Java / Kotlin — for Android and JVM-based systems
• TypeScript — for browser and Node.js applications (WebSocket transport)
• Go — official binding added in 1.9.0, sponsored by SoftBank Corp
• zenoh-pico (C) — pure C, microcontroller and RTOS targets

The plugin ecosystem

The zenohd router supports plugins that extend its capabilities. Official plugins include:

• zenoh-plugin-rest — RESTful HTTP API for Zenoh networks, bridging HTTP clients to Zenoh pub/sub
• zenoh-bridge-mqtt — bidirectional bridge between MQTT brokers and Zenoh networks, enabling existing MQTT infrastructure to integrate with Zenoh
• zenoh-plugin-ros2dds — bridge between Zenoh and DDS-based ROS2 systems
• zenoh-backend-filesystem — persistent storage backend using the filesystem
• zenoh-backend-rocksdb — high-performance persistent storage
• zenoh-backend-s3 — S3-compatible object storage backend
• zenoh-backend-influxdb — time-series storage backend

The MQTT bridge deserves particular attention for DevOps teams: if you have existing MQTT infrastructure (IoT devices, sensors) but want to move toward Zenoh's more capable topology model, the bridge lets existing MQTT devices communicate natively with Zenoh nodes without firmware updates.

Zenoh vs the alternatives

vs MQTT — MQTT is the dominant IoT messaging protocol and broadly supported. Its limitation is the broker requirement: every device routes through a central broker even if two devices are on the same local network, adding latency and a single point of failure. MQTT also has no native storage or query semantics. Zenoh's broker-optional design and built-in storage/query layer address both limitations. For simple IoT scenarios with existing MQTT infrastructure, MQTT remains appropriate; for complex distributed systems or edge-to-cloud spanning deployments, Zenoh's architecture is superior.

vs Kafka — Kafka is the dominant choice for high-throughput data pipelines and event streaming in cloud architectures. It's not designed for constrained devices, doesn't run on embedded hardware, and requires significant operational overhead (ZooKeeper or KRaft, broker cluster, topic management). Zenoh covers different use cases: it's better for latency-sensitive, geographically distributed, or hardware-spanning deployments. For pure high-throughput log streaming in cloud environments, Kafka remains the right choice.

vs DDS/ROS2 — DDS (OMG Data Distribution Service) is the incumbent for real-time robotics and defense systems. It offers rich QoS policies and reliable pub/sub but has complex discovery overhead and doesn't scale naturally to internet scope or constrained devices. Zenoh was explicitly designed as a superset of DDS's capabilities with better scalability and resource efficiency, by the same people who designed parts of DDS.

vs gRPC/REST — gRPC and REST are request/response protocols excellent for service APIs. They don't provide pub/sub semantics, don't handle data at rest natively, and don't adapt to peer-to-peer topologies. They're the right choice when you have a clear client/server relationship; Zenoh is the right choice when data flow is more complex and topology more dynamic.

Getting started

Run a Zenoh router with Docker:

docker run --init -p 7447:7447/tcp -p 7447:7447/udp \
  eclipse/zenoh:latest

Install the Python binding and run a subscriber:

pip install eclipse-zenoh

python3 -c "
import zenoh, time

def listener(sample):
    print(f'>> [{sample.key_expr}]: {sample.payload.deserialize(str)}')

session = zenoh.open(zenoh.Config())
sub = session.declare_subscriber('demo/**', listener)
print('Listening... Press CTRL-C to stop')
time.sleep(3600)
session.close()
"

Publish from another terminal:

python3 -c "
import zenoh
session = zenoh.open(zenoh.Config())
session.put('demo/temperature', 'Hello from Zenoh!')
session.close()
"

Who it's for

Good fit:

• Robotics teams building ROS2-based systems who want cloud connectivity and better resource efficiency than DDS
• Automotive / SDV projects needing communication from ECUs to cloud backend
• Edge computing architectures that span constrained hardware and cloud services
• IoT deployments that need more than MQTT offers — storage, queries, peer-to-peer
• Distributed systems teams tired of maintaining protocol translation bridges
• Projects that need to span from microcontroller to data center on a single protocol

Not the right fit:

• Simple IoT projects with existing MQTT infrastructure and no need to extend to cloud or constrained hardware — MQTT works fine
• Pure cloud microservice architectures — Kafka, gRPC, and REST are better suited and more operationally familiar to most teams
• Teams that need a large existing community and broad third-party tooling — Zenoh's ecosystem is growing but smaller than MQTT or Kafka's

My take

Zenoh solves a real problem that most infrastructure engineers haven't fully articulated yet: the protocol gap between the embedded world and the cloud world. MQTT gets you from sensor to broker. Kafka gets you from broker to data lake. DDS handles real-time robot communication. None of them spans the full range, which is why every serious IoT or robotics deployment ends up with translation bridges.

Zenoh is the protocol that could eliminate most of those bridges. The Apache 2.0 license, Rust implementation, and Eclipse Foundation governance are all positive signals for long-term viability. The ROS2 adoption through rmw_zenoh is probably the fastest path to wider adoption — as robotics teams migrate to it, the ecosystem builds.

For DevOps engineers specifically, Zenoh is most immediately relevant for infrastructure that spans hardware boundaries: if you're building platforms that need to collect data from embedded sensors, process it at the edge, and feed it to cloud services — and you're tired of maintaining MQTT-to-Kafka adapters or DDS bridges — Zenoh is worth a serious look. The Docker-based router makes it straightforward to add to an existing stack, and the MQTT bridge plugin means you don't have to abandon existing infrastructure to start.

It's a specialized tool for a specific class of distributed system problems. But for teams who have those problems, it's the most coherent solution available.