RobustMQ: one Rust broker for MQTT, Kafka, NATS, AMQP and mq9

What RobustMQ is trying to collapse into one process

Most messaging stacks accumulate brokers. An IoT team runs MQTT for devices, a streaming team runs Kafka for analytics, and a service mesh may run NATS for low-latency pub/sub. Each broker has its own storage, its own cluster coordination, its own authentication model and its own operational runbook. Data that crosses from one to the other gets copied, and the copy is the part that breaks.

RobustMQ's answer is a single Rust binary with three internal components: a Meta Service that handles metadata over Raft consensus, a Broker that parses and routes protocols, and a Storage Engine with pluggable backends. The README describes the boundary as fixed: a new protocol means implementing only the Broker parsing layer, and a new storage backend means implementing only the Storage Engine interface. The intended audience is teams that would otherwise run two or three brokers side by side, particularly those spanning edge gateways and cloud clusters.

The claim that matters is the data flow. A message published over MQTT is written once to the shared storage layer and can then be consumed over Kafka, subscribed to over NATS, consumed over AMQP, or delivered to an mq9 agent mailbox. Whether that holds up in practice is exactly what the project's own status labels tell you to be careful about.

The three-component architecture and what it buys you

The split between Meta Service, Broker and Storage Engine is the load-bearing decision. Meta Service runs Raft consensus internally, which is why the README can claim zero external dependencies: there is no ZooKeeper or etcd to deploy alongside it. That removes a class of operational work, and it also means metadata availability is tied to the same cluster you are debugging when something goes wrong.

Storage is configurable per topic, with memory, RocksDB and file backends listed, plus automatic cold data tiering to S3. The NATS path is described as pure in-memory routing with no disk writes, which is a different storage decision than the MQTT path makes. So the unified storage layer is unified in interface, not in behaviour: choosing NATS semantics means choosing to skip persistence for that traffic.

Multi-tenancy is implemented across all protocols rather than bolted onto one, with data isolation and independent permissions per tenant. Shared subscriptions are also listed, with the README framing them as breaking the concurrency-equals-partition-count limit so consumers can scale elastically. That is a real difference from Kafka's consumer group model, and it is one of the few places where RobustMQ describes a concrete advantage rather than a feature list.

Installing RobustMQ and publishing a first MQTT message

The README's Quick Start section is titled One-Line Install, but the truncated README does not preserve the command itself, so the exact install invocation cannot be reproduced here. The project homepage at robustmq.com and the docs directory in the repository are where the current instructions live. What the repository does show is a makefile at the top level and a docker/ directory, which are the two build and packaging paths you would expect from a Rust workspace.

If you build from source, the workspace layout is the map. The Cargo.toml lists the members, and the broker binary comes from src/broker-server, with protocol implementations in src/mqtt-broker, src/kafka-broker, src/nats-broker, src/amqp-broker and src/mq9-core. The workspace version is pinned at 0.4.11, matching the most recent release tag.

[workspace.package]
version = "0.4.11"
edition = "2021"
license = "Apache-2.0"

Those keys come straight from the workspace manifest in Cargo.toml, and they tell you which version you are building and under which licence. Expect a long first build: the member list includes a storage engine, a rule engine, a connector layer and gRPC clients, so the dependency graph is not small.

Once a broker is running, the example directory is the fastest way to see a real client interaction. example/ws-mqtt.html is a browser-based MQTT client, and example/mqtt-cluster/, example/test-network-docker/ and example/test-network-k8s/ cover cluster, Docker and Kubernetes topologies respectively. The Docker and Kubernetes examples are the ones to read before planning a deployment, because they show how the components are meant to be wired together rather than just started.

The repository also ships a CLI, built from src/cli-command, and a benchmarking tool from src/cli-bench. The README does not document their flags, so treat the source as the reference until the documentation catches up.

mq9 is the part that is genuinely different, and the part to be most careful with

mq9 is RobustMQ's fifth protocol and its bet on AI agent infrastructure. It addresses two problems: how agents find each other, and how they exchange messages when the recipient is not online. The registry uses AGENT.REGISTER and AGENT.DISCOVER commands with full-text and semantic vector search. Communication uses a persistent mailbox per agent, with three priority tiers (critical, urgent, normal) and FETCH+ACK pull consumption, so messages wait for the recipient instead of being dropped.

The comparison the README draws is against combining a general-purpose registry such as etcd or Consul with a general-purpose queue such as Kafka or NATS. The argument is that a single broker shares runtime, storage, network and cluster coordination, while a stitched-together stack duplicates all four. That is a fair structural argument, and it is also the kind of argument that only pays off if the broker itself is mature.

Integration paths are broad on paper: an mq9.a2a SDK facade wrapping the official a2a-sdk for A2A-compliant agents, a native NATS client usable from any language, SDKs for Python, Go, TypeScript, Java and Rust, a langchain-mq9 toolkit for LangChain and LangGraph, and an MCP Server exposing JSON-RPC 2.0. The workspace confirms the internal pieces exist, with src/mq9-core, src/common/llm-engine and src/common/search-engine as members.

The caveat is prominent. The feature table marks mq9 as demo validated and in development, not available. The README also says production readiness is targeted for 0.4.0, while the current release is 0.4.11, which suggests that target has slipped or that the statement predates the release numbering. Either way, do not read the version number as a maturity signal here.

Where RobustMQ is the wrong tool

The README states the project is in early development and not yet production-ready. That sentence should decide most evaluations on its own. If your workload cannot tolerate a broker that may change behaviour between releases, this is not the project for you yet, regardless of how the feature table reads.

The protocol status table is the second filter. MQTT 3.x and 5.0 core, session persistence and recovery, shared subscriptions, authentication and ACL, Grafana and Prometheus monitoring, and the web management console are all marked available. Kafka is in development. NATS, AMQP and mq9 are demo validated and in development. If your reason for looking at RobustMQ is the promise of consuming MQTT-published data over Kafka, that specific path is not something the project claims is finished.

There is also a design tension worth naming. The pitch is one storage layer for everything, but the NATS path is described as pure in-memory with no disk writes. A team expecting uniform durability guarantees across protocols will not get them, because the protocols are configured to behave differently by design. Per-topic storage configuration is a feature, and it is also a way to end up with a cluster whose data loss characteristics vary by topic.

Finally, Rust is a constraint as much as a benefit. A team without Rust experience can run the binary and use the CLI, but debugging a broker written in Rust is a different skill set than debugging one written in Java or Go. The repository includes a flake.nix and shell.nix, which helps reproducibility, and it does not remove the language barrier.

Alternatives and the real difference in approach

The obvious alternative for the MQTT use case is EMQX, which is also written in Erlang rather than Rust and is a mature MQTT broker with a long operational history. The difference is scope: EMQX is an MQTT broker, while RobustMQ is attempting a multi-protocol engine on shared storage. If all you need is MQTT and you want the smallest number of unknowns, the single-protocol broker is the lower-risk choice.

For the multi-agent use case, the alternative is the composition the README argues against: etcd or Consul for discovery plus Kafka or NATS for transport. That stack is assembled from components with independent track records, and the cost is that you operate and reason about each one separately, with no shared storage and no single tenant model spanning them.

For the streaming side, Kafka itself remains the reference implementation, and RobustMQ's Kafka compatibility is explicitly in development. Anyone whose workload is already Kafka-shaped should treat RobustMQ as something to watch rather than something to migrate to.

Within the Rust messaging space, the related searches around this project point at rumqttc and Rmqtt, which are client libraries rather than brokers. That distinction matters: if what you actually need is a Rust MQTT client, a broker project is the wrong dependency, and a client library is the right one.

Maintenance, licensing and the upgrade question

The repository is not archived, and the last push was on 2026-07-31, the same date as the v0.4.11 release. The three most recent releases, v0.4.9, v0.4.10 and v0.4.11, all landed within four days of each other at the end of July 2026. That release cadence is worth noting for upgrade planning: patches arrive in clusters, and there is no long-term support branch described in the README.

Because the project describes itself as early development, upgrading across minor versions should be treated as a migration rather than a patch. The README does not document a rollback procedure, and it does not describe a compatibility policy between releases. Verify both before you depend on a specific version, and pin the version you build against, which is the 0.4.11 declared in the workspace manifest.

The licence is Apache-2.0, declared in both Cargo.toml and package.json. The repository also carries a CLA.md, a LICENSING.md and a licenserc.toml, which means some files or dependencies may be handled differently from the top-level licence. Read LICENSING.md and deny.toml before shipping, and get your own legal review if the distinction matters to your organisation. Nothing here is legal advice.

The operational surface is smaller than a typical broker deployment because there are no external dependencies to run alongside it, but the documentation surface is correspondingly thin. The README does not document the CLI flags, the install command, or the upgrade path, so budget time for reading source and the docs directory rather than expecting a complete manual.

Editorial conclusion

Adopt RobustMQ today only if you need an MQTT broker and can accept an early-development project: the MQTT core, session persistence, shared subscriptions, auth and ACL are all listed as available, and the Grafana and Prometheus monitoring and web console ship with it. Do not adopt it for Kafka, NATS or AMQP traffic, because the README marks those as in development or demo-validated, and it warns the project is not production-ready. Verify two things first: whether the install path in the Quick Start works on your target OS, and whether the licence terms in LICENSE and LICENSING.md cover the deployment you have in mind. Everything else can wait until the protocol you care about leaves demo status.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes