All Products
Search
Document Center

ApsaraMQ for MQTT:Limits

Last Updated:Sep 08, 2025

This topic describes the limits and specifications for certain metrics in ApsaraMQ for MQTT. When you use ApsaraMQ for MQTT, do not exceed these limits to prevent program exceptions. The following tables provide more details about these limits.

If you purchase a Platinum Edition instance of ApsaraMQ for MQTT, you can customize certain metrics. These metrics are marked in the tables below. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

Instance limits

Limitations

Limit

Description

Instance name

  • Length: 3 to 64 characters

  • Allowed characters: digits (0-9), letters (a-z, A-Z), hyphens (-), and underscores (_). The name is not case-sensitive.

  • Uniqueness: The instance name must be unique within the same region.

You cannot specify a custom name when you create an instance. By default, the name of a new instance is the same as its instance ID. You can modify the name in the ApsaraMQ for MQTT console.

Messaging TPS of a single instance

Throttling is based on your purchased specifications. If the messaging transactions per second (TPS) of ApsaraMQ for MQTT exceeds the limit of your specifications, issues such as disconnections, response timeouts, and message discards may occur on clients. This applies to clients such as open source MQTT clients and cloud software development kits (SDKs). In this case, reliable message delivery is not guaranteed.

A single MQTT client typically does not handle a large volume of messages, and some SDKs are not designed for high throughput. The messaging TPS for a single MQTT client should not exceed 20. If you require a higher message volume for a server-side application, consider using an ApsaraMQ for RocketMQ client.

Number of online connections for a single instance

Throttling is based on your purchased specifications. If the number of connections exceeds the limit, new connection requests may be rejected.

By default, ApsaraMQ for MQTT provides monitoring alarms for the number of online connections. You can adjust the monitoring threshold as needed.

Number of subscription relationships for a single instance

If the number of subscriptions exceeds the specification limit, new subscriptions may fail. The corresponding client connections may be disconnected, and the integrity of the subscription relationships cannot be guaranteed.

By default, ApsaraMQ for MQTT provides monitoring alarms for the number of subscription relationships. You can adjust the monitoring threshold as needed.

IP address that corresponds to the instance endpoint

None

This IP address can change at any time. Do not hardcode the IP address. The ApsaraMQ for MQTT product team is not responsible for issues that occur in the following situations:

  • The client connects using an IP address instead of a domain name, and the original IP address becomes invalid after the domain name resolution is updated.

  • A firewall policy on your client's network is set for the IP address, and the new IP address is blocked by your firewall after the domain name resolution is updated.

Topic limits

Restrictions

Limit

Description

Topic name

  • Length: 3 to 64 characters

    Note

    The topic length refers to the total length of the parent topic and its child topics.

  • Allowed characters: digits (0-9), letters (a-z, A-Z), hyphens (-), and underscores (_). The name is not case-sensitive.

  • Uniqueness: The parent topic name must be unique within the same instance.

When you send and receive messages using ApsaraMQ for MQTT, the topic length must be within the specified limits. Otherwise, you cannot send or subscribe to messages.

Number of parent topics for a single instance

25

If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

Cross-region use of topics

Not supported

If you configure rules for data exchange between ApsaraMQ for MQTT and ApsaraMQ for RocketMQ, the related resources must be in the same region.

Client limits

Limits

Limit

Description

Client ID

  • Length: Up to 64 characters

  • Allowed characters: digits (0-9), letters (a-z, A-Z), hyphens (-), and underscores (_).

When you send and receive messages using ApsaraMQ for MQTT, the Client ID must not exceed the length limit. Otherwise, the connection is disconnected.

Group ID

  • Length: 7 to 64 characters

  • Allowed characters: digits (0-9), letters (a-z, A-Z), hyphens (-), and underscores (_). The ID must start with "GID_" or "GID-".

  • Uniqueness: The Group ID must be unique within the same instance.

When you send and receive messages using ApsaraMQ for MQTT, the Group ID length must be within the specified limits. Otherwise, you cannot send or subscribe to messages.

Device ID

  • Length: The Client ID format is <GroupID>@@@<DeviceID>. The length limit for the Device ID is dynamic. You must ensure that the total length of the Client ID does not exceed 64 characters.

  • Allowed characters: digits (0-9), letters (a-z, A-Z), hyphens (-), and underscores (_).

  • Uniqueness: The Device ID must be unique within the same Group ID.

When you send and receive messages using ApsaraMQ for MQTT, the Client ID must not exceed the length limit. Otherwise, the connection is disconnected.

Number of topics a client can subscribe to

30

Each client can subscribe to a maximum of 30 topics simultaneously. If this limit is exceeded, new subscription requests fail. Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

When you calculate the number of subscribed topics, a subscription that contains a wildcard character counts as one subscription. Subscriptions to different child topics under the same parent topic are counted as separate subscriptions. For example, A/# is counted as one subscription, and A/# and A/a1/# are counted as two subscriptions.

Number of wildcard subscription relationships

A maximum of 100 wildcard subscription relationships are allowed for each parent topic.

The service limits the number of active wildcard subscription relationships for each parent topic. If this limit is exceeded, the service loads only 100 relationships. This may cause some subscribed clients to not receive messages. You must strictly control the number of relationships. For example, for the same parent topic A, subscriptions to A/#, A/a1/#, and A/a2/# are counted as three subscription relationships.

Maximum heartbeat interval

8 minutes

When sending and receiving messages with ApsaraMQ for MQTT, the maximum heartbeat interval is 8 minutes.

Limits on data flow and client status rules

Limits

Limit

Description

Number of rules per instance

100

If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

Rule deduplication

For the same internal resource, you can create only one rule of each type.

For example, you can create only one online/offline notification rule for a Group ID, and only one data inbound rule and one data outbound rule for an MQTT topic.

Region limit

You cannot create rules across regions. The instances of the data source and data destination for a rule must be in the same region.

For example, if you create a data outbound rule and the source ApsaraMQ for MQTT instance is in the China (Hangzhou) region, you can select only an ApsaraMQ for RocketMQ instance in the China (Hangzhou) region as the data destination.

ApsaraMQ for MQTT instance version

Only ApsaraMQ for MQTT instances of version 3.x.x support this feature.

Only ApsaraMQ for MQTT instances of version 3.x.x can be purchased.

ApsaraMQ for RocketMQ instance version

Only 4.0 series instances are supported.

When ApsaraMQ for MQTT and ApsaraMQ for RocketMQ exchange data through data inbound or data outbound rules, only ApsaraMQ for RocketMQ 4.0 series instances support these rules. 5.0 series instances are not supported.

Message sending and receiving limits

Note

ApsaraMQ for MQTT does not support last will and testament messages or retained messages.

Limits

Limit

Description

Message size

64 KB

The message payload must not exceed this limit. Otherwise, the message is discarded.

Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

Message retention period

3 days

ApsaraMQ for MQTT retains offline messages only when QoS=1 and cleanSession=false. The messages are retained for a maximum of 3 days and are automatically deleted by automatic scrolling after this period. For more information about Quality of Service (QoS) and cleanSession, see Glossary.

Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

QoS and cleanSession

  • The configuration of QoS and cleanSession is supported only by client-side SDKs, not by server-side SDKs.

  • The following configurations are not supported:

    • QoS=2 and cleanSession=false

    • QoS=0 and cleanSession=false

When you send and receive messages using ApsaraMQ for MQTT:

  • If cleanSession=true, you can set QoS to 0, 1, or 2.

  • If cleanSession=false, you cannot set QoS to 2 or 0. ApsaraMQ for MQTT does not support this configuration.

Token validity period

30 days

When you call the operation to apply for a token, if the value of ExpireTime is greater than 30 days, the operation still succeeds and returns a token without an error. However, the actual validity period is still 30 days.

Offline message visibility time

10 seconds

After the service pushes a message for the first time, it must wait for a timeout or failure to confirm whether the message is converted to an offline message. The corresponding latency is typically 5 to 10 seconds.

Number of stored offline messages

1 million

The service limits the number of offline messages stored for each instance. If this limit is exceeded, the service starts to clear messages from the earliest ones. Therefore, use the persistence subscription pattern reasonably to avoid generating too many useless offline messages.

If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.

Number of message push retries

  • Client-side consumption

    • When QoS=1: 16 times

    • When QoS=2: 16 times

  • Server-side consumption

    10 times

The maximum number of times the ApsaraMQ for MQTT service retries pushing a message when the consumer fails to receive the message or consumption fails.

Cloud API limits

For information about the queries per second (QPS) limits on cloud API calls, see QPS limits.