| Parameter name | +Launch | +Growth | +Scale | +Enterprise | +Description | +
| Sessions | +2K | +4K | +20K | +Unlimited | +Maximum number of client sessions managed by the broker, including both active connections and persistent sessions that are temporarily disconnected but still maintained by the broker for quick reconnection. +Once a session is expired or explicitly removed, it no longer counts toward the session limit and the slot becomes available for a new session | +
| Total msg/sec | +1K | +2K | +10K | +Unlimited | +Total throughput of messages processed per second, including both incoming and outgoing `MQTT_PUBLISH` packets. +It does not include acknowledgment packets used in QoS 1 and 2 flows (such as `PUBACK`, `PUBREC`, etc.), nor other MQTT control packets like `CONNECT`, `SUBSCRIBE`, `UNSUBSCRIBE`, etc. | +
| Integrations | +5 | +10 | +50 | +Unlimited | +Maximum number of persistent Application clients and +Integrations managed by the broker, including both connected and temporarily disconnected ones | +
| Monthly traffic | +100GB | +200GB | +1TB | +Unlimited | +Monthly traffic refers to the total amount of data transmitted through the TBMQ broker, including both incoming and outgoing MQTT messages. +Traffic is measured as the sum of all MQTT packet payloads sent and received by clients. If the monthly allowance is exceeded, additional usage is billed at $0.15 per GB | +
| Device persistent messages rate limits | +50 | +100 | +500 | +Unlimited | +Total number of messages processed per second for all Device clients with persistent sessions. +These clients are subscribers, and if they are offline, the messages are stored in Redis to be delivered when they reconnect | +
| Application topic size | +1 GB | +1 GB | +1 GB | +Unlimited | +Maximum size of the Kafka topic used to store persisted messages for a disconnected Application client. Each client has a dedicated topic, and messages are retained until delivered or the size limit is reached | +
| Application topic TTL | +1 day | +1 day | +1 day | +Unlimited | +Time-to-live for messages stored in Kafka topics for Application clients. If a client remains disconnected beyond this period, undelivered messages will be discarded automatically | +
| Integration topic size | +1 GB | +1 GB | +1 GB | +Unlimited | +Maximum size of the Kafka topic used to store persisted messages for a disconnected Integration. Each Integration has a dedicated topic, and messages are retained until delivered or the size limit is reached | +
| Integration topic TTL | +1 day | +1 day | +1 day | +Unlimited | +Time-to-live for messages stored in dedicated Kafka topics for each Integration. If the Integration remains disconnected beyond this period, undelivered messages will be automatically discarded | +
| Device persisted messages storage | +50 | +100 | +500 | +Unlimited | +Maximum number of messages that can be stored for each Device client with a persistent session while it is offline. Once the limit is reached, older messages are dropped to make room for new ones | +
| Device persisted messages TTL | +1 day | +1 day | +1 day | +Unlimited | +"Time to live" parameter for messages stored for Device persisted clients while they are offline | +
| Stats TTL | +1 month | +1 month | +1 month | +Unlimited | +"Time to live" parameter for statistics persistence. This includes metrics visible on the UI: sessions, subscriptions, incoming messages, outgoing messages, etc. | +
| Session TTL | +1 day | +1 day | +1 day | +Unlimited | +"Time to live" parameter for persistent session that is disconnected. If a client remains disconnected beyond this duration, its session data will be automatically removed from the broker | +
| Client incoming messages rate limit | +Up to 10 per second, not exceeding 300 per minute | +Up to 10 per second, not exceeding 300 per minute | +Up to 10 per second, not exceeding 300 per minute | +Unlimited | +Total number of incoming messages per publisher client with any Quality of Service (QoS) level | +
| Client outgoing messages rate limit | +Up to 10 per second, not exceeding 300 per minute | +Up to 10 per second, not exceeding 300 per minute | +Up to 10 per second, not exceeding 300 per minute | +Unlimited | +Total number of outgoing messages per non-persistent subscriber client with Quality of Service (QoS) level equal to 0 ("AT_MOST_ONCE") | +
| In-flight messages | +100 | +100 | +100 | +Unlimited | +Maximum number of incoming QoS 1 and QoS 2 messages from a publisher that can be awaiting acknowledgment. Acknowledgment is sent after the message is successfully persisted by the broker. +If this limit is exceeded, the client is disconnected to prevent overload | +
| Client pre-connect messages | +100 | +100 | +100 | +Unlimited | +Maximum number of messages the broker will queue per client during the connection handshake phase. If this limit is exceeded before the client completes the connection, the client will be disconnected | +
| Message size | +1 MB | +1 MB | +1 MB | +Unlimited | +Maximum size of the payload in an MQTT_PUBLISH packet that the broker will accept. Larger messages will be rejected unless using the Enterprise plan with custom limits | +
| Uptime SLA | +99.9% | +99.9% | +99.95% | +Custom | +Represents the percentage of time a broker is expected to be fully operational and accessible | +
Customer may cancel the subscription and purchase a perpetual license. @@ -1168,7 +1363,7 @@ selfManagedPlan:
It can be your advantage for a quick start with the platform. These 10 hours can be used for consulting, training, or development services. Training sessions imply pre-defined topics, while Consulting may cover various technical questions, platform configurations, or your Use Case-related issues. The above services are conducted online. Alternatively, these 10 hours can be used to support you in the PoC, MVP, or ready-for-market solutions development by a dedicated development unit from ThingsBoard. @@ -1182,7 +1377,6 @@ selfManagedPlan:
@@ -1354,5 +1548,71 @@ selfManagedPlan:
+ Dedicated plan features the deployment of a dedicated MQTT broker cluster on the ThingsBoard cloud, expertly managed by the TBMQ team. + The cluster comprises several TBMQ nodes, ensuring high availability and uninterrupted service. + A dedicated load balancer is included to seamlessly distribute your incoming traffic across multiple targets. + Additionally, each plan includes sessions and message limits, as well as persistence limits to store essential data during offline periods. + It provides a 99.99% uptime SLA. Focus on your solution while we manage the servers for you on our cloud. +
++ BYOC (Bring Your Own Cloud) deployment option allows you to leverage your existing cloud infrastructure while integrating our powerful MQTT broker cluster. + This flexibility ensures that you can maintain control over your cloud environment, optimize costs, and meet specific regulatory or compliance requirements. + The TBMQ team is responsible for managing the cluster and providing technical support. +
++ TMPS refers to the total number of messages processed per second by the TBMQ cluster. + This metric includes both incoming and outgoing messages but counts only 'MQTT PUBLISH' packets. + For instance, if you have 100 devices each sending 10 messages per second, the incoming volume would be 1,000 messages per second. + If there are 2 subscribers consuming these messages, resulting in 2,000 outgoing messages per second, the TMPS would be 3,000. + TMPS provides a comprehensive measure of the messaging throughput handled by the TBMQ cluster, ensuring efficient and reliable communication for your IoT applications. +
++ Application client is a specialized type of client designed for scenarios with high message subscription volumes. + It uses a dedicated message queue and consumer to ensure high performance and enables message persistence when the subscriber is offline. + This makes it well-suited for scenarios where reliable message delivery is necessary, and message loss is unacceptable. +
++ Device client is a standard type of client that can be configured to be persistent or non-persistent based on the connection settings. + Persistent device messages are stored in a database while their corresponding device subscribers are offline. + The limit for device persistent messages is configured per TBMQ cluster, rather than per individual client, ensuring efficient resource management. +
++ For BYOC (Bring Your Own Cloud) deployment, contact us to discuss your specific needs and preferences. + We will work with you to determine the required infrastructure, load patterns, and cloud options that best suit your environment. + Additionally, we will assess your cluster requirements and Service Level Agreement (SLA) needs to ensure optimal performance and reliability. +
++ Yes, TBMQ subscriptions have sessions, messages, and storage limits. See subscription documentation for more details. +
+