RobustMQ 0.4.0 Released
RobustMQ 0.4.0 is officially released today.
If 0.3.0 was "the first step after finding our direction," then 0.4.0 is "the first time we found our footing." This is a milestone release — MQTT enters the trial stage, the multi-protocol pipeline is fully connected, the first version of the mq9 core is born, and the rule engine is complete.
Note: 0.4.0 is still in an early stage. MQTT has entered the trial phase, but Kafka, AMQP, NATS, and mq9 are still iterating rapidly. We plan to mature further in 0.5.0, expected to release between August and September.
What 0.4.0 Delivered
Looking back at the work in this release, it focused on six things.
First, RobustMQ MQTT enters the trial stage. Performance optimizations and deadlock fixes stabilized three core scenarios: publish, subscribe, and mass connection creation. This is the first time MQTT has reached a state where real users can start trying it.
Second, the multi-protocol pipeline is fully connected. End-to-end paths for MQTT, Kafka, AMQP, and NATS over a unified storage layer are all working. Write once, consume via any protocol — the architectural feasibility is verified at runtime.
Third, mq9 is introduced. The first version of the protocol design and core implementation is complete, purpose-built for AI Agent asynchronous communication. Multi-language SDKs (Python, Go, JS, Java, C#) and a LangChain integration are released alongside — developers can connect an Agent to mq9 with a single line of code.
Fourth, the rule engine is complete. RobustMQ's first step into "data integration" — filtering, transforming, and routing messages in-flight. A large set of Connectors lets rule engine output go directly to downstream systems.
Fifth, delayed tasks are designed. Protocol design and core implementation are done, covering foundational use cases like order timeouts, scheduled notifications, and retry scheduling.
Sixth, extensive refactoring, bug fixes, and module improvements. HTTP API and Admin refactoring, storage layer improvements, multiple performance bottleneck and deadlock fixes, module boundary cleanup. These don't add new features, but they determine whether the system can actually run in production.
What 0.5.0 Plans to Do
0.4.0 found its footing — 0.5.0 keeps moving forward. 0.5.0 is expected between August and September, with many 0.4.x patch releases in the meantime.
First, continue improving RobustMQ MQTT. Entering the trial stage is not the finish line — the goal is production-ready.
Second, continue improving mq9. Protocol refinement, performance and stability improvements, and ongoing exploration of best practices for AI Agent asynchronous communication based on real use cases.
Third, complete Kafka Producer/Consumer. Finish the Kafka protocol implementation and open up the core edge-to-cloud pipeline.
Fourth, explore the integrated edge–cloud–AI pipeline. MQTT for edge device data ingestion, Kafka for cloud big-data platform integration, mq9 for AI Agent async communication — one dataset, multiple views, covering the full pipeline from device to AI.
By the time 0.5.0 ships, MQTT should be further matured, the edge-to-cloud and MQTT-to-Kafka integrated pipeline should be initially connected, and mq9 should have completed its initial exploration.
Details on each area follow.
RobustMQ MQTT
Entering the Trial Stage
One of the most important outcomes in 0.4.0 is that MQTT has finally reached the point where real users can start trying it.
The stability investment in this release is the largest of any recent version. During load testing we continuously fixed multiple performance bottlenecks and deadlocks:
Performance optimizations: Reduced latency for publishing messages, subscribing to messages, and creating connections. These weren't single-point improvements — they came from a continuous cycle of load testing, identifying issues, fixing them, and testing again. Each round brought performance closer to a production-ready level.
Stability fixes: Load testing exposed a tricky deadlock — when a large number of connections were created simultaneously, lock contention on the two-level DashMap used for connection management caused the system to freeze. The system should have slowly processed these requests rather than deadlocking. We redesigned the connection management data structure so that mass connection creation runs stably.
Three core scenarios validated under load:
- Stable message subscription
- Stable message publish
- Stable mass connection creation
All three running stably means RobustMQ MQTT can handle real IoT ingestion scenarios. There are still many edge cases that need real users in production environments to discover and validate, which is why we're calling this the "trial stage" rather than "production-ready."
Rule Engine Complete
0.4.0 finishes the rule engine — RobustMQ's first step into data integration.
The rule engine lets RobustMQ do more than pass messages through. It can filter, transform, and route messages in-flight. These capabilities are especially important in IoT scenarios, where device data often needs lightweight processing before being forwarded to downstream systems.
With the rule engine done, the natural next step is building out a wide set of Connectors.
Extensive Connectors
0.4.0 adds a large set of Connector implementations, letting rule engine output go directly to various downstream systems. This is a critical piece for RobustMQ entering enterprise production environments — even with the best protocol and storage layers, users can't truly put it to work without a connector ecosystem.
The connector architecture follows RobustMQ's plugin-based design philosophy: adding a new connector doesn't require touching core code, and the community can extend it going forward.
Delayed Tasks
0.4.0 completes the delayed task design.
Delayed tasks are a foundational capability of a messaging system — send with a specified delay, consumed only when the time comes. This is essential for order timeouts, scheduled notifications, retry scheduling, and similar use cases.
0.4.0 completes the protocol design and core implementation of delayed tasks. Subsequent releases will continue refining precision, scale, and observability.
Agent Communication Protocol: mq9
A Major Introduction
0.4.0 introduces mq9 — RobustMQ's fifth native protocol layer, purpose-built for AI Agent asynchronous communication.
Why build mq9?
Agents are not services. Services run continuously; Agents are ephemeral — they might live for only a few seconds. Today, when Agent A sends a message to Agent B and B is offline, the message is simply lost. Every team building multi-Agent systems works around this with ad-hoc solutions — Redis pub/sub, polling a database, custom task queues. They work, but they're all detours.
mq9 solves this directly: built around the mailbox abstraction, each Agent has its own mailbox. The sender sends the message and moves on; the receiver picks it up whenever it's ready. Messages are persisted to storage and auto-cleaned on TTL expiry. Sender and receiver don't need to be online at the same time.
What did 0.4.0 deliver?
- First version of the mq9 protocol design: mailbox abstraction, priority, TTL, key-based compaction, and other core semantics fully defined
- First version of the mq9 core implementation: protocol parsing and routing on top of RobustMQ's unified storage layer
- NATS protocol compatibility: NATS clients in any language connect at zero cost
mq9 wasn't an impulsive idea — it grew naturally from three years of RobustMQ architecture investment. The unified storage + protocol view layer design means we can add new protocols for new use cases without touching the core storage.
RobustMQ SDK + LangChain SDK
To bring mq9 into AI developers' workflows, 0.4.0 ships multi-language SDKs at the same time:
- RobustMQ SDK: Python, Go, JS, Java, C#
- langchain-mq9: native LangChain framework integration
LangChain is currently the largest ecosystem for Python AI developers. langchain-mq9 wraps mq9's core operations as LangChain Tools — developers connect their Agent to mq9 with one line of code, no adapter code needed.
The mq9 protocol, the SDKs, and the framework integration are all in place. This line is initially complete as of 0.4.0.
Multi-Protocol
All Four Protocols Connected End-to-End
0.4.0 completes a verification that is critical to RobustMQ's overall positioning: end-to-end pipelines for MQTT, Kafka, AMQP, and NATS are all fully connected.
A message written via any protocol can be consumed via any other protocol. The underlying layer is a unified Shard storage — no data replication, no bridge conversion. MQTT messages can be consumed by Kafka; AMQP messages can be consumed by NATS.
The engineering significance of this goes far beyond a demo. It means the "unified storage + multi-protocol views" architecture that RobustMQ has committed to for three years actually works. Each protocol has its own semantics — Kafka has offsets and partitions, MQTT has QoS and retain, NATS has subjects and queue groups, AMQP has exchanges and bindings. Making all of these protocols behave correctly on the same storage required substantial work in the storage abstraction layer.
The multi-protocol pipeline in 0.4.0 covers only basic subscribe-and-consume. Advanced features for each protocol are still being built out. But the architectural feasibility has been verified at runtime — that's one of the most important engineering achievements in 0.4.0.
Bug Fixes and Refactoring
HTTP API and Admin Refactoring
0.4.0 includes a refactoring pass on the HTTP API and Admin modules.
As features accumulated, the original API design became less clear. This refactoring makes API layering cleaner, naming more consistent, and error handling more uniform. The Admin module was reorganized accordingly.
Refactoring like this doesn't add new features, but it determines the system's maintainability. RobustMQ is a long-term project — periodic internal refactoring is a routine part of keeping the codebase healthy.
Storage Layer Improvements
0.4.0 continues improving the storage layer. All three storage engines (Memory, RocksDB, File Segment) are being refined, and replica synchronization is progressing.
The storage layer is RobustMQ's core. Whether it's the unified multi-protocol view or mq9's mailbox semantics, everything ultimately depends on storage stability and performance. Investment here will continue indefinitely.
Code Simplification, Bug Fixes, Module Cohesion
Behind 0.4.0 is a large amount of invisible engineering work.
Between every release we review the codebase continuously — where the design is unclear, where there are latent issues, where evolution is needed. 0.4.0 is no different. This refactoring doesn't produce new features, but it makes the architecture more stable, the code clearer, and future extension easier.
This release also includes a large number of bug and performance fixes. Some were exposed during load testing, some were reported by community users, some were caught in regular code reviews. Each fix makes system behavior more predictable in edge cases.
The codebase itself is being continuously simplified and made more cohesive. Module boundaries are becoming clearer, duplicated logic has been extracted, and classes with unclear responsibilities have been split or merged. The line count hasn't grown quickly, but each line belongs in its place more than the previous version.
This is a long-term engineering culture: every refactoring leaves the architecture cleaner, every refactoring leaves the code more solid.
Getting Started
One of RobustMQ's design goals is zero-dependency minimal deployment.
curl -fsSL https://raw.githubusercontent.com/robustmq/robustmq/main/scripts/install.sh | bash
broker-server startOnce the cluster is ready, verify with any MQTT client:
mqttx pub -h localhost -p 1883 -t "test/topic" -m "Hello RobustMQ!"
mqttx sub -h localhost -p 1883 -t "test/topic"You can also open the web management console at http://localhost:58080 to view cluster status.
Full quick-start documentation: https://robustmq.com/QuickGuide/Overview.html
The release of 0.4.0 marks RobustMQ's transition from "steady progress after finding direction" to "core capabilities beginning to stand on solid ground." MQTT enters the trial stage, the multi-protocol pipeline is connected, mq9 is introduced, and the SDK ecosystem is initially complete. These are the results of months of sustained investment.
But 0.4.0 is still early. There are no shortcuts in foundational software — every step must be taken deliberately. We'll continue at the pace of "slow is smooth, smooth is fast" — going deep and stable in each direction before moving on.
Project: https://github.com/robustmq/robustmq
Feedback and trial use are welcome.