All Products
Search
Document Center

ApsaraMQ for RocketMQ:Quotas and limits

Last Updated:Dec 17, 2025

ApsaraMQ for RocketMQ defines quotas and limits for instance resources, instance types, and related parameters. To prevent application errors, do not exceed these limits when you use ApsaraMQ for RocketMQ.

Parameter limits

The limits on resource names, remarks, and other parameters in the following table cannot be adjusted. You must strictly follow these specifications to prevent system errors caused by special characters or lengths that exceed the limits.

Parameter

Limit

Description

Instance name

  • Character limit: Supports Chinese characters, letters (a–z, A–Z), digits (0–9), and underscores (_).

  • Length limit: 1 to 128 characters.

None.

Topic name

  • Character limit: Supports letters (a–z, A–Z), digits (0–9), underscores (_), and hyphens (-).

  • Length limit:

    • Serverless instances: 1 to 128 characters.

    • Non-Serverless instances: 1 to 60 characters.

Reserved characters: Do not use the following reserved characters, prefixes, or suffixes for topic names.

  • Reserved characters

    • TBW102

    • BenchmarkTest

    • SELF_TEST_TOPIC

    • OFFSET_MOVED_EVENT

    • SCHEDULE_TOPIC_XXXX

    • RMQ_SYS_TRANS_HALF_TOPIC

    • RMQ_SYS_TRACE_TOPIC

    • RMQ_SYS_TRANS_OP_HALF_TOPIC

  • Special prefixes

    • rmq_sys_

    • %RETRY%

    • %DLQ%

    • rocketmq-broker-

    • rocketmq-proxy-

  • Special suffixes

    • _REPLY_TOPIC

Use short and common characters for topic names and avoid special characters. Special characters can cause parsing errors. An excessively long name may cause the system to reject message sending and receiving operations.

LiteTopic name

  • Character limit: Supports letters (a–z, A–Z), digits (0–9), underscores (_), and hyphens (-).

  • Length limit: 1 to 64 characters.

Use short and common characters for LiteTopic names and avoid special characters. Special characters can cause parsing errors. An excessively long name may cause the system to reject message sending and receiving operations.

LiteTopic time-to-live (TTL)

  • Default value: None. This is a required parameter.

  • Value range: 30 to 720, or -1. The unit is minutes. The value must be an integer. A value of -1 indicates that the LiteTopic never expires.

This parameter specifies the expiration time for LiteTopic resources under the current topic. If no new messages are written to a LiteTopic for a period that reaches the specified TTL, the LiteTopic expires and is automatically deleted. If the value is -1, the LiteTopic never expires and is not deleted. You can set this field only when the message type is Lite.

Consumer group name

  • Character limit: Supports letters (a–z, A–Z), digits (0–9), underscores (_), and hyphens (-).

  • Length limit:

    • Serverless instances: 1 to 128 characters.

    • Non-Serverless instances: 1 to 60 characters.

Reserved characters: Do not use the following reserved characters or prefixes for consumer group names.

  • Reserved characters

    • DEFAULT_CONSUMER

    • DEFAULT_PRODUCER

    • TOOLS_CONSUMER

    • FILTERSRV_CONSUMER

    • __MONITOR_CONSUMER

    • CLIENT_INNER_PRODUCER

    • SELF_TEST_P_GROUP

    • SELF_TEST_C_GROUP

    • CID_ONS-HTTP-PROXY

    • CID_ONSAPI_PERMISSION

    • CID_ONSAPI_OWNER

    • CID_ONSAPI_PULL

    • CID_RMQ_SYS_TRANS

  • Special characters

    • CID_RMQ_SYS_

    • CID_HOUSEKEEPING

None.

Instance remarks

  • Character limit: Supports Chinese characters, letters (a–z, A–Z), digits (0–9), and underscores (_).

  • Length limit: 1 to 256 characters.

None.

Topic remarks

Group remarks

ACL Credentials

  • Character limit: The AccessKey ID, AccessKey secret, and Token support only letters (a–z, A–Z) and digits (0–9).

  • Length limit: Maximum of 1024 characters.

None.

Request timeout

  • Default value: 3000 ms.

  • Value range: This parameter specifies a local client behavior. The value range is not limited.

The request timeout is the waiting time for a local synchronous call on the client. You can set a reasonable value based on your application to avoid long thread-blocking periods.

Message size

Maximum: 4 MB.

This limit applies only to the message body and does not include compression.

You can compress messages and control the payload size to avoid transferring large files. If a message exceeds the size limit, you can split the message or use OSS and transfer the message URL instead.

Custom message properties

  • Character limit: All visible characters.

  • Quantity limit: Maximum of 128 properties per message.

  • Length limit: The total length of the key and value of a property cannot exceed 16 KB.

Reserved properties: Do not use the following reserved property keys as custom property keys.

Reserved property keys

  • TRACE_ON

  • MSG_REGION

  • KEYS

  • TAGS

  • DELAY

  • RETRY_TOPIC

  • REAL_TOPIC

  • REAL_QID

  • TRAN_MSG

  • PGROUP

  • MIN_OFFSET

  • MAX_OFFSET

  • BUYER_ID

  • ORIGIN_MESSAGE_ID

  • TRANSFER_FLAG

  • CORRECTION_FLAG

  • MQ2_FLAG

  • RECONSUME_TIME

  • UNIQ_KEY

  • MAX_RECONSUME_TIMES

  • CONSUME_START_TIME

  • POP_CK

  • POP_CK_OFFSET

  • 1ST_POP_TIME

  • TRAN_PREPARED_QUEUE_OFFSET

  • DUP_INFO

  • EXTEND_UNIQ_INFO

  • INSTANCE_ID

  • CORRELATION_ID

  • REPLY_TO_CLIENT

  • TTL

  • ARRIVE_TIME

  • PUSH_REPLY_TIME

  • CLUSTER

  • MSG_TYPE

  • INNER_MULTI_QUEUE_OFFSET

  • _BORNHOST

  • __LITE_TOPIC

None.

MessageGroup

  • Character limit: All visible characters.

  • Length limit: 1 to 64 bytes.

MessageGroup is the group identifier for ordered messages. It is typically set to an identifier for a group of messages that must be processed in order, such as an order ID or a user ID.

Message sending retries

  • Default value: 3.

  • Value range: Unlimited.

Message sending retries are handled by a built-in retry policy in the client software development kit (SDK) and are not visible to the application. Do not set this value too high to avoid blocking business threads.

If a message fails to be sent after the maximum number of retries, you must implement a fallback mechanism on the business side to ensure message reliability.

Message consumption retries

  • Default value: 16.

  • Maximum limit: 1000.

You can set a reasonable value as needed. Avoid using retries to trigger an infinite loop. An excessive number of retries can significantly increase system pressure.

Transaction resolution check interval

  • Default value: 60 seconds.

  • Value range: This value cannot be customized.

The transaction resolution check interval is the period after which the producer client checks the transaction resolution of a half-transactional message that was not committed because of a system restart or an exception.

Do not set this interval too short. Frequent check calls can affect system performance.

First check time for half-transactional messages

  • Default value: Same as the [Transaction resolution check interval].

  • Maximum limit: 1 hour.

None.

Maximum timeout for half-transactional messages

  • Default value: 4 hours.

  • Value range: This value cannot be customized.

If a half-transactional message is not committed because of a system restart or an exception, the producer client checks its status at the specified transaction resolution check interval. If no result is returned after the maximum timeout period, the half-transactional message is forcibly rolled back.

You can monitor this metric to avoid transaction exceptions.

Maximum delay for scheduled messages

  • Subscription and pay-as-you-go Standard Edition instances, and Serverless Standard and Professional Edition instances support a maximum delay of 7 days.

  • Subscription and pay-as-you-go Professional Edition and Platinum Edition instances support a maximum delay of 40 days.

You can set the delay for scheduled messages to an hour-level interval. Avoid long delays.

PushConsumer consumption timeout

  • Default value: 230 minutes.

  • Value range: This is a system-level configuration and cannot be changed.

The PushConsumer consumption timeout is controlled by the ApsaraMQ for RocketMQ server side.

If a message is not processed within the timeout period, the system forcibly marks the consumption as failed and retries. This may cause a small number of duplicate messages.

PushConsumer local cache

  • Default values:

    • Maximum number of cached messages: 1024.

    • Maximum cache size: 64 MB.

  • Value range: You can customize these settings. The values are not limited.

When the consumer type is PushConsumer, the client SDK caches some messages locally to improve consumer throughput and performance. The number and size of cached messages must be within the limits of the system memory.

PushConsumer retry interval

  • Default values:

  • Value range: This value cannot be customized.

None.

PushConsumer consumption concurrency

  • Default value: 20 threads.

  • Value range: You can customize this setting. The value is not limited.

None.

Maximum batch size for message retrieval

  • Default value: 32.

  • Value range: This is a system-level configuration and cannot be changed.

This parameter specifies the maximum number of messages that a consumer can retrieve from the server at a time. You can set a reasonable value as needed. Retrieving too many messages at once can cause many duplicate messages if consumption fails.

SimpleConsumer maximum invisible duration

  • Default value: None. This is a required parameter.

  • Value range: Minimum: 10 seconds. Maximum: 12 hours.

The invisible duration is the total time required for message processing plus the retry interval after a failure. You can set this value to be slightly longer than the actual time required.

Consumer long polling timeout

Value range: Minimum: 5 seconds. Maximum: 20 seconds.

You can customize this value within the specified range.

After you set a long polling timeout, if no messages are ready on the server, the client request is blocked until a new message arrives or the timeout period elapses.

Long polling can significantly reduce invalid empty requests and reduce the pressure on both the client and the server when the message volume is low.

Subscription relationship

Filter expression length limit: 4000 characters (including TAG and SQL filters).

For more information about subscription relationships, see Subscription.

Resource quotas

ApsaraMQ for RocketMQ limits metrics such as QPS and concurrency for certain operations based on production environment stability and O&M experience. These quotas are sufficient for most scenarios. If the quotas provided by ApsaraMQ for RocketMQ do not meet your business requirements in special scenarios, you can contact ApsaraMQ for RocketMQ technical support for assistance.

Limit

Limit value

Description

Subscription and pay-as-you-go instances

Serverless instances

Number of instances per region

The total number of instances of all types cannot exceed 1000.

None.

Message sending and receiving TPS per instance

This is determined by the purchased instance type. For more information about the specific limits, see Instance type limits.

Automatic scaling

The message sending and receiving TPS reflects the processing performance of the current instance. If the actual TPS exceeds the limit of the instance type, the instance is throttled. You must upgrade the instance type promptly.

Message retention period

  • Minimum: 24 hours.

  • Maximum: 720 hours.

  • Minimum: 24 hours.

  • Maximum: 720 hours.

To manage storage costs, you can extend the retention period as long as possible. A longer retention period provides a longer window for troubleshooting and data backfill.

Number of inflight messages per consumer group

Maximum: 2500.

Maximum: 2500.

An excessive number of inflight messages in a consumer group may slow down the consumer response. You must monitor this metric and investigate the cause promptly.

Number of LiteTopics that a single consumer can subscribe to

Maximum: 2000.

Maximum: 2000.

Subscribing to too many LiteTopics with a single consumer may affect client performance. You can submit a ticket to increase the maximum value.

Maximum consumption TPS for each LiteTopic

200

200

You can create hundreds of thousands to millions of LiteTopics under a topic. The total consumption TPS of the topic is not affected.

Operation limits

ApsaraMQ for RocketMQ is a fully managed Platform as a Service (PaaS). Therefore, it limits some high-risk O&M operations and features that are available in open-source Apache RocketMQ. If you have special requirements, you can contact ApsaraMQ for RocketMQ technical support.

Limit

Description

Compatibility with Apache RocketMQ Admin tools

ApsaraMQ for RocketMQ does not support using the Apache RocketMQ Admin API or command-line interface (CLI) to manage instances, topics, and groups.

To manage resources using APIs, use the OpenAPI provided by Alibaba Cloud. The Alibaba Cloud OpenAPI supports multi-language SDKs and CLI commands.

Apache RocketMQ Request-Reply messages

ApsaraMQ for RocketMQ does not support sending Apache RocketMQ Request-Reply messages.

Apache RocketMQ Streaming component

ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ Streaming component. You can deploy it yourself in an Alibaba Cloud environment or use the data integration feature of ApsaraMQ for RocketMQ to implement lightweight data integration and computing.

Apache RocketMQ MQTT component

ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ MQTT component. Use the ApsaraMQ for MQTT service provided by Alibaba Cloud, which offers more complete features.

Apache RocketMQ EventBridge component

ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ EventBridge component. Use the EventBridge service provided by Alibaba Cloud, which offers more complete features.

Apache RocketMQ-Connector component

ApsaraMQ for RocketMQ does not provide a managed service for the Apache RocketMQ-Connector component. You can use the data integration feature of ApsaraMQ for RocketMQ to implement message data inflow and outflow.

Instance type limits

  • All Standard Edition instances and Single Node Edition instances of the Professional Edition do not support burstable elastic computing. You must plan your resource usage in advance to prevent instance throttling when burst traffic exceeds the specification limits during high-watermark runtime.

  • The topic and group quotas for a single instance are based on practices in large-scale production environments and meet most business requirements. You can split and isolate your business into different instances by department and domain. Avoid running all your business in a single instance.

  • The TPS specification for message sending and receiving is calculated based on the sum of sent and received normal messages, with a message size of 4 KB as the benchmark. When you calculate the TPS for advanced message types and large messages, you must multiply by the corresponding rate. For more information about the calculation method, see Calculation specifications.

  • If the actual TPS for message sending and receiving exceeds the upper limit of your purchased instance type:

    • If the instance has elastic TPS enabled, the instance can run normally within the [Base Specification, Elastic Specification] range. The elastic TPS usage is charged on a pay-as-you-go basis. If the TPS exceeds the upper limit of the elastic capacity, the instance is still throttled.

    • For more information about the billing of elastic TPS for non-Serverless instances, see Elastic TPS fees. For more information about the billing of elastic TPS for Serverless instances, see Serverless elastic TPS fees.

    • If the instance does not support or has not enabled the elastic TPS feature, ApsaraMQ for RocketMQ throttles the instance.

  • If too many clients connect to an ApsaraMQ for RocketMQ instance, the server uses significant resources to maintain the connections. This can severely affect server stability. Make sure that the number of client connections does not exceed the upper limit for your instance type.

Serverless instances

Limits for existing Serverless Standard and Professional Edition instances

Instance series

Instance type

Maximum message sending and receiving TPS (times/second)

Maximum connections

Internet traffic

Maximum topic quota

Maximum group quota

Standard Edition

rmq.s3.nxlarge

50,000

10,000

Unlimited. Billed based on actual usage.

5,000

5,000

Professional Edition

rmq.p3.nxlarge

50,000

Supports minute-level automatic elastic scaling after 50,000 TPS.

30,000

Unlimited. Billed based on actual usage.

5,000

5,000

Note
  • Number of concurrent online clients: The number of online producer or consumer objects. One producer or one consumer object counts as one client.

  • Resource count: The total number of topics and consumer groups.

Deployment architecture

Capacity mode

TPS specification

Maximum number of concurrent online clients

Free quota for concurrent online clients

Maximum resource count

Free quota for resource count

Maximum number of LiteTopics that can be created or subscribed to

Shared

By cumulative usage

All

5,000

500

3,000

100

/

Reserved + Elastic

[2,000, 20,000]

5,000

1,000

3,000

200

(20,000, 50,000]

8,000

2000

3,000

200

(50,000, 100,000]

10,000

3,000

3,000

200

(100,000, 200,000]

20,000

5,000

3,000

200

Dedicated

Reserved + Elastic

5,000

3,000

2,000

3,000

300

300,000

10,000

6,000

4,000

4,000

300

600,000

15,000

8,000

6,000

6,000

500

720,000

[20,000, 50,000]

10,000

8,000

6,000

500

1,000,000

(50,000, 100,000]

20,000

10,000

6,000

500

1,500,000

(100,000, 200,000]

40,000

20,000

8,000

1,000

2,400,000

(200,000, 300,000]

80,000

40,000

10,000

1,500

4,700,000

(300,000, 500,000]

100,000

50,000

16,000

2,000

6,300,000

(500,000, 1,000,000]

200,000

100,000

40,000

3,000

11,600,000

Non-Serverless (subscription and pay-as-you-go) instances

Standard Edition instance types

Instance sub-series

Instance type

Maximum base TPS for message sending and receiving (times/second)

Maximum burst elastic TPS for message sending and receiving (times/second)

Maximum connections

Downstream Internet bandwidth (Mbps)

Free topic quota

Maximum topic quota

Maximum consumer group quota

Maximum number of LiteTopics that can be created or subscribed to

Single Node Edition (No longer sold)

rmq.s1.micro

500

Not applicable

This instance type does not support burst elasticity.

2,000

1 to 1000

Customizable.

100

100

1,000

/

Cluster High-availability Edition

rmq.s2.2xlarge

2,000

4,000

300

150,000

rmq.s2.4xlarge

4,000

4,000

250,000

rmq.s2.6xlarge

6,000

6,000

500

300,000

Note

If the highest specification (rmq.s2.6xlarge) of the Standard Edition for topics and consumer groups still cannot meet your business requirements, you can upgrade to the Professional Edition and select a suitable instance type.

Professional Edition instance types

Instance sub-series

Instance type

Maximum base TPS for message sending and receiving (times/second)

Maximum burst elastic TPS for message sending and receiving (times/second)

Maximum connections

Downstream Internet bandwidth (Mbps)

Free topic quota

Maximum topic quota

Maximum consumer group quota

Maximum number of LiteTopics that can be created or subscribed to

Single Node Edition (No longer sold)

rmq.p1.micro

500

Not applicable

This instance type does not support burst elasticity.

2,000

1 to 1000

Customizable.

150

150

1,500

/

Cluster High-availability Edition

rmq.p2.4xlarge

4,000

2,000

4,000

250,000

rmq.p2.6xlarge

6,000

3,000

6,000

300,000

rmq.p2.10xlarge

10,000

5,000

10,000

1,000

600,000

rmq.p2.20xlarge

20,000

10,000

10,000

800,000

rmq.p2.30xlarge

30,000

15,000

12,000

2,000

1,000,000

rmq.p2.40xlarge

40,000

20,000

12,000

1,200,000

rmq.p2.50xlarge

50,000

20,000

14,000

1,400,000

rmq.p2.100xlarge

100,000

30,000

26,000

2,200,000

rmq.p2.120xlarge

120,000

40,000

30,000

2,700,000

rmq.p2.150xlarge

150,000

50,000

38,000

3,300,000

rmq.p2.200xlarge

200,000

60,000

50,000

4,500,000

Note

If the highest specifications (rmq.p2.10xlarge or later) of the Professional Edition for topics and consumer groups still cannot meet your business requirements, you can submit a ticket for assistance.

Platinum Edition instance types

Instance sub-series

Instance type

Maximum base TPS for message sending and receiving (times/second)

Maximum burst elastic TPS for message sending and receiving (times/second)

Maximum connections

Downstream Internet bandwidth (Mbps)

Free topic quota

Maximum topic quota

Maximum consumer group quota

Maximum number of LiteTopics that can be created or subscribed to

Cluster High-availability Edition

rmq.u2.10xlarge

10,000

5,000

10,000

1 to 1000

Customizable.

200

3,000

4,000

600,000

rmq.u2.20xlarge

20,000

10,000

10,000

800,000

rmq.u2.30xlarge

30,000

15,000

12,000

1,000,000

rmq.u2.40xlarge

40,000

20,000

10,000

1,200,000

rmq.u2.50xlarge

50,000

20,000

14,000

1,400,000

rmq.u2.60xlarge

60,000

22,000

16,000

1,600,000

rmq.u2.70xlarge

70,000

24,000

18,000

1,700,000

rmq.u2.80xlarge

80,000

26,000

20,000

1,800,000

rmq.u2.90xlarge

90,000

28,000

24,000

2,000,000

rmq.u2.100xlarge

100,000

30,000

26,000

2,200,000

rmq.u2.120xlarge

120,000

40,000

30,000

2,700,000

rmq.u2.150xlarge

150,000

50,000

38,000

3,300,000

rmq.u2.200xlarge

200,000

60,000

50,000

4,500,000

rmq.u2.250xlarge

250,000

70,000

51,000

5,600,000

rmq.u2.300xlarge

300,000

80,000

52,000

6,300,000

rmq.u2.350xlarge

350,000

90,000

53,000

7,500,000

rmq.u2.400xlarge

400,000

100,000

54,000

9,300,000

rmq.u2.450xlarge

450,000

120,000

60,000

10,400,000

rmq.u2.500xlarge

500,000

140,000

66,000

11,600,000

rmq.u2.550xlarge

550,000

160,000

72,000

12,800,000

rmq.u2.600xlarge

600,000

200,000

80,000

14,000,000

rmq.u2.1000xlarge

1,000,000

300,000

134,000

23,200,000

Note

If the topic and consumer group quotas of the Platinum Edition still cannot meet your business requirements, you can submit a ticket for assistance.