All Products
Search
Document Center

ApsaraMQ for RocketMQ:Quotas and limits

Last Updated:Jan 07, 2026

ApsaraMQ for RocketMQ imposes quotas and limits on its instances, types, and parameters. Adhere to these limits when you use ApsaraMQ for RocketMQ to prevent application errors.

Parameter limits

The limits for resource names and remarks in the following parameters cannot be adjusted. You must strictly adhere to the specifications to prevent system processing errors that are caused by special characters or excessive length.

Parameter

Limit

Description

Instance name

  • Allowed characters: Chinese characters, letters, digits, and underscores (_).

  • Length: 1 to 128 characters.

None.

Topic name

  • Allowed characters: Letters, digits, underscores (_), and hyphens (-).

  • Length:

    • For Serverless series instances: 1 to 128 characters.

    • For non-Serverless series instances: 1 to 60 characters.

System reserved characters: Do not use the following reserved characters or characters with special prefixes or suffixes as 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, and excessively long names may cause messages to be rejected.

LiteTopic name

  • Allowed characters: Letters, digits, underscores (_), and hyphens (-).

  • Length: 1 to 64 characters.

Use short and common characters for LiteTopic names and avoid special characters. Special characters can cause parsing errors, and excessively long names may cause messages to be rejected.

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 is the expiration time for LiteTopic resources under the current topic. If no new messages are written to any LiteTopic under the topic for a period that reaches the specified TTL, the LiteTopic expires and is automatically deleted. A value of -1 indicates that the LiteTopic never expires and is not deleted. You can set this field when the message type is Lite.

Consumer group name

  • Allowed characters: Letters, digits, underscores (_), and hyphens (-).

  • Length limit:

    • For Serverless series instances: 1 to 128 characters.

    • For non-Serverless series instances: 1 to 60 characters.

System reserved characters: Do not use the following reserved characters or characters with special prefixes as 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

  • Allowed characters: Chinese characters, letters, digits, and underscores (_).

  • Length: 1 to 256 characters.

None.

Topic remarks

Group remarks

ACL credentials

  • Allowed characters: The AccessKey ID, AccessKey secret, and Token support only letters and digits.

  • Length: Up to 1,024 characters.

None.

Request timeout

  • Default value: 3,000 ms.

  • Value range: This parameter is a client-side behavior, so the value range is not limited.

The request timeout is the waiting time for synchronous calls on the client. You can set a reasonable value based on your application to avoid blocking threads for an extended period.

Message size

Up to 4 MB.

The calculation is based only on the size of the message body and does not include message compression.

You can compress and control the payload size for message transmission and avoid transferring oversized files. If a message exceeds the size limit, you can split the message or use OSS for storage and transmit the message URL instead.

Custom message properties

  • Allowed characters: All visible characters.

  • Quantity limit: Up to 128 properties per message.

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

System reserved properties: Do not use the following reserved properties as keys for custom properties.

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

  • Allowed characters: All visible characters.

  • Length: 1 to 64 bytes.

The MessageGroup is the group identifier for ordered messages. It is typically set to an identifier for a group of messages that requires ordering, such as an order ID or a user ID.

Message sending retries

  • Default value: 3.

  • Value range: Unlimited.

Message sending retry is a retry policy built into the client software development kit (SDK) and is transparent to the application. Do not set this value too high, because it may block 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: 1,000.

You can set a reasonable value for consumption retries as needed. Avoid using retries to trigger infinite loops, because too many retries can significantly increase system pressure.

Abnormal Transaction Check Interval

  • Default value: 60 seconds.

  • Value range: Cannot be customized.

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

Do not set the interval too short, because frequent check calls can affect system performance.

First check time for half-transactional messages

  • Default value: Same as the value of the Transaction resolution check interval parameter.

  • Maximum limit: 1 hour.

None.

Maximum timeout for half-transactional messages

  • Default value: 4 hours.

  • Value range: Cannot be customized.

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

You can monitor this metric to prevent transaction exceptions.

Maximum delay for scheduled messages

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

  • The Professional and Platinum editions support a maximum of 40 days for both subscription and pay-as-you-go plans.

You can set the delay for scheduled messages in hours. Avoid setting excessively long delays.

PushConsumer consumption timeout

  • Default value: 230 minutes.

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

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

If a message is not processed within the consumption timeout period, the system forcibly marks the consumption as failed and initiates a retry. This may cause a small number of messages to be redelivered.

PushConsumer local cache

  • Default values:

    • Maximum cache size (messages): 1,024.

    • Maximum cache size (memory): 64 MB.

  • Value range: Can be customized. No limit.

When the consumer type is PushConsumer, the client caches messages locally in the SDK 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:

    • For non-ordered delivery, the interval increases at a tiered rate. For more information, see PushConsumer retry policy.

    • For ordered delivery, the interval is 1,000 ms.

  • Value range: Cannot be customized.

None.

PushConsumer consumption concurrency

  • Default value: 20 threads.

  • Value range: Can be customized. No limit.

None.

Maximum batch size for message retrieval

  • Default value: 32 messages.

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

This is the maximum number of messages that a consumer can retrieve from the server at one time. You can set a reasonable value based on your business. Retrieving too many messages at once can cause numerous redeliveries if consumption fails.

SimpleConsumer maximum invisibility duration

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

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

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

Consumer long polling timeout

Value range: 5 seconds to 20 seconds.

You can adjust the value within this 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 is reached.

Using long polling can significantly reduce invalid empty requests when the message volume is low. This reduces the load on both the client and the server.

Subscription relationship

Filter expression length limit: 4,000 characters (including TAG filtering and SQL filtering).

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 operations and maintenance (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 item

Limit

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 1,000.

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.

Elastic and adaptive

The message sending and receiving TPS reflects the processing performance of the current instance. If the actual TPS exceeds the specification limit, 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.

You can extend the retention period as much as possible while keeping storage costs manageable. A longer retention period provides a longer window for troubleshooting and data backtracing.

Number of inflight messages per consumer group

Up to 2,500.

Up to 2,500.

An excessive number of inflight messages in a consumer group can slow down consumer responses. You should monitor this metric and investigate the cause promptly.

Number of LiteTopics a single consumer can subscribe to

Up to 2,000.

Up to 2,000.

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

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, the system restricts some high-risk O&M operations and features that are available in open source Apache RocketMQ. For special requirements, you can contact ApsaraMQ for RocketMQ technical support for assistance.

Limit item

Description

Apache RocketMQ Admin tool compatibility

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 through an API, 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 from 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 instances of the Standard Edition series and the Single Node Edition instances of the Professional Edition series do not support burstable elastic computing. You must plan your resource usage in advance to prevent instance throttling caused by traffic bursts that exceed the specification limit during high-watermark runtime.

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

  • The TPS specification for message sending and receiving is calculated based on the sum of messages sent and received, with normal message types and a message size of 4 KB as the benchmark. When you calculate the TPS for messages with advanced features or large messages, you must multiply the result 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 specification:

    • If the instance has elastic TPS enabled, the instance runs normally within the range of the base specification to the elastic specification. The elastic TPS usage is billed on a pay-as-you-go basis. If the TPS exceeds the upper limit of the elastic capacity, the instance is throttled.

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

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

  • If there are too many connections between clients and an ApsaraMQ for RocketMQ instance, the server consumes significant resources to maintain these connections. This severely affects server stability. Therefore, do not let the number of client connections exceed the upper limit of the instance type.

Serverless series instances

Limits for existing Standard and Professional Edition Serverless instances

Instance main series

Instance type

Maximum message sending and receiving TPS (TPS)

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 adaptive elasticity for TPS over 50,000.

The upper limit for adaptive elasticity is 300,000.

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

Cumulative

All

5,000

500

3,000

100

/

Reserved + Elastic

[2000, 20,000]

5,000

1,000

3,000

200

(20,000, 50,000]

8,000

2,000

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 series (subscription and pay-as-you-go) instances

Standard Edition instance types

Instance sub-series

Instance type

Maximum base TPS (TPS)

Maximum burst TPS (TPS)

Maximum connections

Public downstream 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 type does not support burst elasticity.

2,000

1 to 1,000

Can be customized.

100

100

1,000

/

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 specifications (rmq.s2.6xlarge) for topics and consumer groups in the Standard Edition do not 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 (TPS)

Maximum burst TPS (TPS)

Maximum connections

Public downstream 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 type does not support burst elasticity.

2,000

1 to 1,000

Can be customized.

150

150

1,500

/

High-availability Edition

rmq.p2.4xlarge

4,000

2,000

4,000

2,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 higher) for topics and consumer groups in the Professional Edition do not meet your business requirements, you can submit a ticket for assistance.

Platinum Edition instance types

Instance sub-series

Instance type

Maximum TPS (transactions per second) for the basic messaging specification

Maximum burst TPS (TPS)

Maximum connections

Public downstream bandwidth (Mbps)

Free topic quota

Maximum topic quota

Maximum consumer group quota

Maximum number of LiteTopics that can be created or subscribed to

High-availability Edition

rmq.u2.10xlarge

10,000

5,000

10,000

1 to 1,000

Can be customized.

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 specifications for topics and consumer groups in the Platinum Edition do not meet your business requirements, you can submit a ticket for assistance.