Why TBMQ The MQTT broker built for real IoT traffic
TBMQ is an open-source MQTT broker built by the ThingsBoard team for large-scale IoT deployments. It supports MQTT 5.0, 3.1.1 and 3.1, scales to 100 million concurrent connections across a masterless cluster, and uses Apache Kafka to guarantee zero message loss. You can self-host TBMQ with Docker or Kubernetes, or run it as a managed service.
Purpose-built for IoT traffic
IoT traffic isn't uniform. Most brokers treat every message the same. TBMQ gives each pattern its own processing path.
Fan-in
Millions of devices publish telemetry continuously. A few backend applications must consume every message in order — even during spikes or partial outages.
Fan-out
A single update or command must reach many subscribed devices at once. One message in, many deliveries out — and every subscriber receives it.
Point-to-point
A publisher targets one subscriber through a unique topic. Command-response and remote-control flows need low-latency, targeted delivery.
Distributed MQTT broker architecture that backs the numbers
TBMQ's throughput and resilience are consequences of its design — not a lucky benchmark run.
PUBACK / PUBREC sent only after Kafka persists ⇒
zero message loss.
tbmq.msg.all
Every PUBLISH lands here.
ZSET · {clientId} queue
tbmq.msg.app.<clientId-1>
tbmq.msg.app.<clientId-2>
tbmq.msg.app.<clientId-N>
No message loss by design
TBMQ doesn't acknowledge a publish until Kafka has durably stored it. If a node fails mid-flight, another resumes from Kafka — nothing is lost between acknowledgment and delivery.
Subscription matching at any scale
Subscriptions live in an in-memory trie, so matching a topic to its subscribers costs the same whether the broker holds a thousand subscriptions or a million — lookup scales with the topic's depth, not the total subscriber count.
Separate paths for publishers and subscribers
DEVICE clients (Redis-backed) and APPLICATION clients (dedicated Kafka topic + consumer thread) are processed independently, so a device spike never delays application delivery.
Symmetric cluster, no coordinator
Every node is identical — no master, no leader election. State is shared through Kafka, so new nodes join and rebalance with zero downtime.
Built on proven foundations
Each technology choice directly determines how the broker behaves under load, during failures, and as the cluster grows.
Apache Kafka
Durable message storage and distribution across the cluster.
Netty
Non-blocking, event-driven network transport for millions of connections per node.
Actor system
Isolated per-client concurrency, so one slow client never blocks another.
In-memory trie
Subscription matching in time proportional to topic length, not subscriber count.
Full MQTT compliance
Fully compliant with the MQTT protocol in both single-node and cluster deployments.
- Multi-node clustering
- X.509, JWT, and HTTP authentication
- Access control lists (ACL)
- REST API for sessions & subscriptions
- Rate limiting for message processing
- Cluster and client metrics monitoring
- MQTT over WebSocket client
- HTTP, MQTT, and Kafka integrations
- MQTT channel backpressure
- Blocked & unauthorized client management
TBMQ Professional Edition adds Single Sign-On (SSO), Role-Based Access Control (RBAC), and White labeling. Compare editions.
Start building with TBMQ
The same broker that scales to 100 million connections runs on a single laptop for development. Get started in minutes.