# Eclipse Zenoh: a Rust pub/sub layer that also stores and queries data

> Zenoh is the reference Rust implementation of a protocol that merges publish/subscribe with geo-distributed storage and queries. It is aimed at robotics, edge and IoT systems where a broker is too much and a raw socket is too little.

**eclipse-zenoh/zenoh** — zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.

- Repository: https://github.com/eclipse-zenoh/zenoh
- Website: https://zenoh.io
- Stars: 3,228 · Forks: 378
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/eclipse-zenoh-zenoh

## The gap Zenoh fills between a broker and a raw socket

Most systems that move sensor data end up choosing between two unsatisfying options. A broker such as MQTT or AMQP gives you routing, but it is a separate process with its own operational cost, and the data is gone once delivered unless you bolt on a database. A raw socket or a shared-memory ring gives you speed, but every consumer has to know where every producer is.

Zenoh's README frames the project as unifying "data in motion, data at rest, and computations", blending pub/sub with geo-distributed storage, queries and computations. That is the pitch: one protocol for the live stream and for the stored copy, with the same key expression addressing both. The audience is visible in the repository topics: robotics, ROS 2, embedded, edge computing, IoT, distributed systems.

The important claim to read carefully is the efficiency one. The README says Zenoh retains "a level of time and space efficiency that is well beyond any of the mainstream stacks". That is the project's own description of itself, and the README does not publish a benchmark table to support it. Treat it as a design goal, not a measured result, until you run your own workload.

## How the protocol is layered in this repository

The workspace layout tells you more about the architecture than the prose does. The zenoh crate is described as the primary and reference implementation of the protocol; the libraries for other languages are bindings to it, with one exception. zenoh-pico is a pure-C implementation, not a binding, which is why it can target microcontrollers where the Rust runtime does not fit.

Below the public crate sits a commons/ directory of internal crates: zenoh-buffers, zenoh-codec, zenoh-protocol, zenoh-keyexpr, zenoh-shm, zenoh-sync, zenoh-runtime and others. The README is explicit that these are not intended to be imported directly and that their public APIs can change at any time. Only zenoh and zenoh-ext carry stable APIs.

Transport is split into one crate per link type under io/zenoh-links: tcp, udp, tls, quic, quic_datagram, ws, serial, unixsock_stream, unixpipe and vsock. That list is the real portability story. If your deployment needs a link that is not in that directory, the protocol does not help you. On top of the transport sits io/zenoh-transport, and on top of that the zenohd router binary, which the README describes as a standalone daemon used to support Zenoh network infrastructure, with plugins under plugins/ adding services such as REST, storage-manager and backend traits.

## Installing Zenoh and running your first publisher and subscriber

The README points to zenoh.io for installation instructions and gives the Rust path directly. Install Cargo and Rust, then bring the toolchain up to date:

```bash
rustup update
```

The README states Zenoh compiles with Rust stable at version 1.75.0 or newer, but warns that some dependencies may require newer Rust versions. The zenoh crate deliberately does not pin its dependencies with "=", so a plain build can drift upward; the commons/zenoh-pinned-deps-1-75 crate exists to lock dependencies to versions compatible with Rust 1.75. Build the workspace with:

```bash
cargo build --release --all-targets
```

The examples directory doubles as a test harness. Start a subscriber in one terminal:

```bash
cargo run --example z_sub
```

and a publisher in another:

```bash
cargo run --example z_pub
```

The subscriber should print the messages the publisher sends. Query/reply works the same way with z_queryable and z_get. Note that when running through Cargo you must use `--` to pass command-line arguments through to the example. If you want shared memory, the README shows it must be enabled explicitly in your dependency declaration, for example `zenoh = {version = "1.5.1", features = ["shared-memory"]}`. That version string is the one the README uses; check the release list for the version you actually want.

## Running the zenohd router and what it actually adds

A pub/sub pair on one host does not need a router. The router matters when peers cannot reach each other directly, or when you want plugin-provided services. The README gives this command:

```bash
cargo run -- --config DEFAULT_CONFIG.json5
```

The DEFAULT_CONFIG.json5 file sits at the repository root, so the router's behaviour is configured through a JSON5 file rather than only through flags. The README states the router's purpose is to support Zenoh network infrastructure and to provide additional services through plugins, and points to the zenohd readme for the plugin directory.

This is where the design trade-off is clearest. Zenoh is peer-to-peer first; the router is infrastructure you add, not a mandatory hop. That is good for latency and for partitions, but it means there is no single place where all traffic is visible by default. If your operations team expects one dashboard showing every topic, you are building that yourself from the REST plugin and the storage-manager plugin, or you are choosing the wrong tool.

## Where Zenoh is the wrong choice

The language support list is the first constraint. Rust is this repository. C has two implementations with the same API (zenoh-c as a Rust binding, zenoh-pico as pure C). C++ wraps the C libraries. Python, Kotlin, Java and Go each have their own repository, and TypeScript is a WebSocket client for a plugin in zenohd, not a native transport. That last detail matters: a TypeScript client depends on the router being present with that plugin enabled, so it is not a peer in the same sense as the Rust or C clients.

The second constraint is maturity signalling. The README states plainly that the commons/ crates are internal and their public APIs can change at any time. If you were tempted to import zenoh-codec or zenoh-keyexpr directly to avoid the higher-level API, that is an unsupported path.

The third is documentation depth. The README does not document rollback, migration between protocol versions, or what happens to stored data when a router is replaced. For a system that advertises geo-distributed storage, the absence of that material in the repository README is a real gap. The troubleshooting page and the Discord server are the routes the README offers when something breaks, which tells you the operational knowledge lives in community channels rather than in the repository.

## Zenoh against DDS, the comparison people actually ask about

The related searches include "zenoh vs dds", and the repository topics include ros2, so the comparison is fair to make. DDS is a standardised pub/sub middleware with a rich quality-of-service model: durability, deadline, latency budget, ownership, content-filtered topics. It was designed for real-time systems and it has a large vendor ecosystem.

Zenoh's approach is different in kind, not just in degree. Instead of a QoS policy matrix, it puts storage and queries into the protocol itself, so a consumer can ask for a value that no producer is currently publishing, and get the stored one. DDS handles that with durability QoS backed by a durability service, which is a heavier configuration. Zenoh's key expressions and its plugin model for backends also mean storage is a pluggable service rather than a broker-side feature.

The honest trade-off: DDS has decades of interoperability specifications behind it and multiple independent implementations that must talk to each other. Zenoh's non-Rust implementations are bindings to the Rust core, except zenoh-pico, so the ecosystem is more centralised. If you need vendor-neutral multi-implementation interoperability, DDS is the safer bet. If you need one protocol that carries both live data and stored data with less configuration, Zenoh is the more direct answer.

## Licence, releases and what maintenance costs you

The repository's Cargo.toml header carries the SPDX identifier EPL-2.0 OR Apache-2.0, and the README badges show both licences. The GitHub licence field reports NOASSERTION, which is a classification artefact rather than a third licence. For adopters, dual licensing under EPL-2.0 or Apache-2.0 is a permissive combination, but the choice is not automatic: EPL-2.0 has reciprocal obligations that Apache-2.0 does not, and the two are offered as alternatives, so which one you rely on is a decision your legal team makes, not one this article can make for you.

Maintenance looks current. The last push to the default branch was on 2026-09-23, and releases 1.10.0 and 1.10.1 landed in August and September 2026, following 1.9.0 in April 2026. The cadence is roughly a minor release every few months with patch releases in between.

Upgrade cost is dominated by the dependency policy. Because zenoh does not pin dependencies with "=", a routine `cargo update` can pull in versions that require a newer Rust toolchain than you ship. The pinned-deps crate is the project's answer, and it is the thing to check before freezing a build image. The internal commons/ crates are explicitly unstable, so any code that reaches past zenoh and zenoh-ext will need attention on every minor release.

## Conclusion

Adopt Zenoh if you are building Rust, C, C++, Python, Kotlin, Java, TypeScript or Go systems that need pub/sub plus queryable storage across machines, and you can run or embed a zenohd router. Do not adopt it if you need a message broker with per-topic retention policies and a management console, or if you cannot add a new protocol to your network. Before committing, verify the licence terms your organisation accepts (the repository offers EPL-2.0 OR Apache-2.0, and the GitHub licence field reports NOASSERTION), check that your target platform is covered by the io/zenoh-links transport crates you need, and compile the exact feature set you plan to ship, since shared memory is not on by default.

## FAQ

### How does Zenoh work?

It is a protocol implementation that unifies data in motion, data at rest and computations, blending traditional pub/sub with geo-distributed storage, queries and computations. The Rust crate in this repository is the reference implementation, and the libraries for other languages are bindings to it, except the pure-C zenoh-pico.

### How do I install Zenoh?

The README points to zenoh.io for installation instructions and gives the Rust route: install Cargo and Rust, run rustup update, then build with cargo build --release --all-targets. Zenoh compiles with Rust stable 1.75.0 or newer, though some dependencies may require newer versions.

### How to run zenoh router?

The zenohd binary is the router. The README shows running it from the workspace with cargo run -- --config DEFAULT_CONFIG.json5, or from target/release/zenohd. It is a standalone daemon that supports Zenoh network infrastructure and provides additional services through plugins.

### What is Zenoh used for?

The repository topics list robotics, ROS 2, IoT, embedded, edge computing and distributed systems. The README describes it as unifying data in motion, data at rest and computations, so it fits systems that need both a live stream and a queryable stored copy under the same key expressions.

### Is Zenoh open source?

Yes. The repository is an Eclipse project, and its Cargo.toml carries the SPDX identifier EPL-2.0 OR Apache-2.0, with badges for both licences in the README. The GitHub licence field reports NOASSERTION, but the source files state the dual licence explicitly.

### What is zenoh-pico and how does it differ from the Rust implementation?

zenoh-pico is a pure-C implementation of Zenoh, listed separately from zenoh-c, which is a Rust library binding. It is the one non-Rust implementation that is not a binding, which is what allows it to target environments where the Rust runtime does not fit.

## Sources

- [eclipse-zenoh/zenoh on GitHub](https://github.com/eclipse-zenoh/zenoh)
- [Issues](https://github.com/eclipse-zenoh/zenoh/issues)
- [Project website](https://zenoh.io)
- [README](https://github.com/eclipse-zenoh/zenoh/blob/main/README.md)
- [Releases](https://github.com/eclipse-zenoh/zenoh/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-zenoh-zenoh