RobustMQ 2026: What We're Building
2025 was the year RobustMQ went from "figuring out the direction" to "direction locked in."
What We Did in 2025
At the start of the year, RobustMQ was still at the prototype stage — architecture unsettled, positioning vague, a lot of things still being tried. The most important work that year wasn't how much code we wrote, but answering a few fundamental questions: what to build, what not to build, and why now.
The positioning that emerged: a next-generation unified communication platform built in Rust, designed from the ground up for AI, IoT, and big data scenarios. Dual-protocol support for MQTT and Kafka, a compute-storage separation architecture underneath, and a storage layer that supports Memory, RocksDB, and File Segment modes.
The engineering output concentrated on three things:
Architecture landed. Meta Service, Broker, and Storage Engine cleanly separated into three layers with stable component boundaries. Meta Service introduced a homegrown Multi Raft implementation supporting multiple independent Raft Groups — laying the groundwork for large-scale deployments.
MQTT feature coverage near-complete. Full MQTT 3.x and 5.0 protocol support, Session persistence, shared subscriptions, QoS 0/1/2, offline messages, delayed messages, and basic rule engine — most common IoT scenarios can now be handled.
Ecosystem tooling filled in. Out-of-the-box Grafana + Prometheus monitoring, a command-line management tool, HTTP Admin API, Web console, Bench CLI — a messaging system can't really ship without the surrounding tools.
2025 wrapped up with the 0.3.0 release. Feature coverage is there, but stability, performance, and production readiness still need work in 2026.
What We're Doing in 2026
Three major versions planned for 2026. The main theme is one thing: make MQTT production-ready, then good, then great — make it the MQTT Broker that users don't want to leave. Kafka and AI MQ are directions we're starting this year, but they're not the focus. Get the core flows working, build the foundation, and see how far we get.
v0.4.0 (Target: May) — MQTT: First Steps Toward Production
One goal for this version: get MQTT Broker to the point where it can run in production.
A full round of code refactoring to eliminate tech debt, stress-testing cluster mode and fixing all blocking bugs, completing the QoS 1/2 acknowledgement edge cases, and seamless Session recovery after node restarts. On the observability side: Prometheus metrics covering all key dimensions, structured logs filterable by ClientID/Topic. Unit test coverage target ≥ 60%, chaos testing covering node failures and network partitions.
v0.5.0 (Target: September) — MQTT Production-Ready + Kafka/AI MQ Core Flows Working
MQTT continues to deepen: rule engine SQL filtering, more Bridge targets, fine-grained rate limiting, slow-subscription alerting. The goal is a smooth enough experience that when users hit problems, there's somewhere to look, tools to diagnose, and someone to respond.
Kafka: Producer/Consumer protocol wired up, Topic management, Java Kafka Client able to connect directly — core flows working is the bar.
AI MQ: Topics backed directly by S3/MinIO object storage, a three-tier cache framework prototype (memory → SSD → object storage), and an Agent communication example built on shared subscriptions. Get the architecture running and validate whether the direction is viable.
v0.6.0 (Target: December) — MQTT Production-Stable + Continued Depth
The MQTT goal is stability — validated by real users at scale, no significant production bugs, clear performance baselines, complete operational tooling. Kafka and AI MQ continue from where 0.5.0 left off, no pressure for completeness.
A Few Final Thoughts
2025 was one person doing this. Time was limited, but the direction got clear — and that matters more than anything.
There's a lot I want to do in 2026, but one thing is clear: making what already exists solid is more important than adding new features. If MQTT can't run reliably in production, nothing else matters. So v0.4.0 is the priority, and we won't skip it to chase progress.
If you're using RobustMQ, or watching from the sidelines — come open an Issue, share feedback, or contribute directly. Every real use case matters more than anything else to us.