Should you evaluate Zenoh?
Zenoh combines pub/sub, storage, queries and computation. Evaluate that combination if your application needs both pushed updates and access to queried or stored data. The project README describes the combined model; it does not establish a performance advantage for your network. Our recorded build and test results give you a starting point for evaluation, not deployment approval.
The repository contains the reference Rust implementation, the zenoh-ext crate, the zenohd router, plugin support and examples. The README limits stable APIs to zenoh and zenoh-ext; internal commons APIs can change at any time. Most other language libraries live in separate repositories, and zenoh-pico is a pure C implementation rather than a Rust binding. Check the binding you intend to ship as its own dependency.
What our sandbox established
Our run on September 17, 2026, used commit 9fcd9cb, whose full hash is 9fcd9cb5d364192c3e8a27e66de76f4bc750d1d5. Installation succeeded in 26 seconds and the build succeeded in 406 seconds. The test command failed after 757 seconds with exit code 101; the harness did not mark it timed out.
Our harness records command success, exit status, elapsed time and parsed test summaries separately. The attached stored parser summaries report 164 passed, 2 failed and 166 total. Replayed Cargo summaries may have been counted more than once, so those aggregates cannot support a unique test count, a pass percentage or a claim that the full suite completed.
The raw tail identifies test_callback_drop_on_undeclare_liveliness_subscriber as a failing test. It panicked after a close operation timed out. That is an observation within the callback_drop_on_undeclare target, not independent confirmation of the aggregate failure count. The tail also contains ignored tests; ignored tests are not failures. It does not establish a second distinct failing case or the cause of the observed timeout.
The build tail reports a dev profile, so this run should not be described as a release-build benchmark. The recorded build duration is the harness wall-clock value, rather than the shorter compiler duration printed inside the tail.
The supplied record contains no separate workload, CLI deployment, throughput, latency, soak or recovery test. It also contains no audit result, so advisory findings and scan coverage are unknown. See how MrKeyoor tests for provenance and general limits. That methodology page was retrieved later and does not establish which current procedures applied to this older run. No new execution supports this correction.
Plan router and plugin builds together
Dynamic plugins should use the same Rust version, Zenoh version or commit, and feature set as zenohd. The router documentation explains that Rust lacks a stable ABI, that some mismatches cause rejection, and that incompatible shared memory layouts can cause a SIGSEGV crash. Keep the router and its dynamic plugins in one reproducible build and validation process.
The router supports explicit listen and connect endpoints, JSON5 or YAML configuration, and multicast scouting responses that can be disabled. Its bundled REST and storage-manager plugins provide additional services. These are documented capabilities, not deployments validated by our build. Test discovery and configured connections under your actual network policy, then check plugin loading and recovery behavior.
The compiler floor also needs attention. The README says Zenoh can compile with Rust stable 1.75.0 or newer but warns that dependencies may require newer versions. It provides a separate pinned-dependencies crate for compatibility with Rust 1.75. Resolve and test the dependencies and features you will actually deploy before relying on that floor.
When an alternative answers the requirement
Mosquitto implements MQTT versions 5.0, 3.1.1 and 3.1. Compare Eclipse Mosquitto first when MQTT protocol compatibility is the requirement. Its README includes broker and client utilities, with a local quick start and configuration requirements for remote clients. Our evidence does not compare its performance or operating cost with Zenoh.
Eclipse Cyclone DDS implements the OMG DDS specification and is a tier-1 middleware for ROS 2. Compare Cyclone DDS when you need a DDS implementation. The Zenoh router documentation separately lists plugins that bridge DDS and ROS 2 communications over Zenoh. In that arrangement, Zenoh can complement existing DDS middleware; a bridge is not evidence that replacing the middleware is necessary.
How to read the ratings
Ratings use a five-point editorial scale: 1 means substantial documented obstacles, 2 means material friction, 3 means usable with important qualifications, 4 means strong evidence within the stated scope, and 5 requires broad corroboration with few unresolved gaps. These are judgments about the evidence described here, not benchmark results or adoption measurements.
Setup ease is 2 because our build required several minutes and the test command failed. Documentation is 4 for the explicit repository boundaries, compiler caveat and router/plugin instructions, without a claim that every deployment path is covered. Community is 4 narrowly for the visible release collaboration and documented contribution and support routes; this does not measure adoption, response times or support quality. Maturity is 3 because the supplied 1.10.1 release records maintenance fixes while our run leaves test and deployment questions unresolved.
Before you commit
Reproduce the named failing target on your intended environment, investigate the timeout, and rerun the relevant suite without replayed-summary ambiguity. Then exercise your application's publish/subscribe and query paths, router topology, required plugins and failure recovery. Use the release and dependency resolution you plan to ship. A successful compilation alone cannot answer those questions.