Zenoh vs Mosquitto: Peer-to-peer vs broker-centric messaging

Both Zenoh and Mosquitto provide publish/subscribe messaging for distributed systems, but they take fundamentally different architectural approaches.

Zenoh was designed to eliminate the broker bottleneck entirely. By default, Zenoh applications communicate peer-to-peer, discovering each other through multicast or gossip protocols. This means two devices on the same local network can exchange messages directly without routing through a central server. Zenoh also unifies data in motion (pub/sub) with data at rest (queries and storage) in a single protocol.

Mosquitto follows the traditional MQTT broker model. All messages route through a central broker, which simplifies discovery and enables features like retained messages and last-will-and-testament. However, it creates a single point of congestion and requires infrastructure even for local device-to-device communication.

Architecture differences

When to choose Zenoh

• Applications requiring direct device-to-device communication without infrastructure
• Scenarios where query capabilities over distributed storage are needed
• Edge deployments with intermittent cloud connectivity
• ROS2 robotics applications (official RMW implementation available)
• Systems requiring both pub/sub and request/response patterns

When to choose Mosquitto

• Existing MQTT ecosystem with many client libraries and tools
• Applications benefiting from broker-managed state (retained messages)
• Teams with existing MQTT expertise and infrastructure
• Scenarios requiring MQTT-specific features like will messages
• Simpler operational model with a single broker to manage

Can they coexist?

Yes. Zenoh provides an MQTT plugin that can bridge to Mosquitto brokers, allowing gradual migration or hybrid deployments where legacy MQTT devices communicate with Zenoh applications through the bridge.