# tbmq **Repository Path**: jerrycell/tbmq ## Basic Information - **Project Name**: tbmq - **Description**: MQTT-BORKER - **Primary Language**: Java - **License**: Apache-2.0 - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2025-03-19 - **Last Updated**: 2025-05-06 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # TBMQ [](https://join.slack.com/t/tbmq/shared_invite/zt-31kk3315e-5jtPw8YAKskq1KkUqTrTyQ) [](https://gitter.im/tbmq/chat?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [](https://builds.thingsboard.io/viewType.html?buildTypeId=TBMQ_Build&guest=1) [](https://hub.docker.com/r/thingsboard/tbmq-node) TBMQ represents an open-source MQTT message broker with the capacity to handle **4M+** concurrent client connections, supporting a minimum of [3M messages per second throughput](https://thingsboard.io/docs/mqtt-broker/reference/3m-throughput-single-node-performance-test/) per single cluster node with low latency delivery. In the cluster mode, its capabilities are further enhanced, enabling it to support more than [100M concurrently connected clients](https://thingsboard.io/docs/mqtt-broker/reference/100m-connections-performance-test/). At ThingsBoard, we've gained a lot of experience in building scalable IoT applications, which has helped us identify three main scenarios for MQTT-based solutions. * In the first scenario, numerous devices generate a large volume of messages that are consumed by specific applications, resulting in a **fan-in** pattern. Normally, a few applications are set up to handle these lots of incoming data. It must be ensured that they do not miss any single message.