This document describes the pricing details and free tiers of each billable item of TDMQ for Apache Pulsar virtual cluster.
Pay-as-You-Go
API call price
TDMQ for Apache Pulsar virtual cluster adopts tiered pricing for API calls. API call fees = (number of API calls for message sending + number of API calls for message consumption) * API call unit price.
The unit price of API call (USD/million calls) is as shown below:
|
|
| Guangzhou, Shanghai, Nanjing, Beijing, Chengdu | Hong Kong (China), Singapore, Seoul, Silicon Valley, Frankfurt | Shenzhen Finance, Beijing Finance |
Tier 1 | N ≤ 1,000 | 0.3 | 0.3 | 0.4 |
Tier 2 | 1,000 < N ≤ 5,000 | 0.2 | 0.3 | 0.4 |
Tier 3 | 5,000 < N ≤ 10,000 | 0.2 | 0.2 | 0.3 |
Tier 4 | 10,000 < N ≤ 50,000 | 0.2 | 0.2 | 0.3 |
Tier 5 | N > 50,000 | 0.2 | 0.2 | 0.2 |
The maximum message body size is 5 MB, and the number of API calls is calculated at different rates according to the message size:
For example, one 10 KB message (publishing or subscribing) request will be charged as 4 API calls.
Note:
The number of API calls for consuming messages refers to the number of messages pushed by the broker to consumers, which may be numerically greater than the number of messages actually acknowledged by consumers. Scenarios where this happens include:
1. When a large number of messages are retained, consumers will prefetch a certain number of messages during connection, and multiple unacknowledged messages will be recorded as multiple API calls for consuming messages. In this case, the number of API calls for consuming messages will be greater than the number of messages actually acknowledged by consumers.
2. When tag messages are consumed, multiple consumers are usually started. In this case, the number of API calls for consuming messages will be greater than the number of messages actually acknowledged by consumers.
Message storage price
TDMQ for Apache Pulsar virtual cluster adopts linear billing for message storage. Message storage fees = message storage size * message storage unit price.
Note:
TDMQ for Apache Pulsar stores a message in three copies by default. Therefore, the billable storage capacity is three times of the total message size.
The unit price of message storage (USD/GB/hour) is as shown below:
Note:
1. When the message retention policy is set to persistent retention, even if a message is consumed, it will still be persistently stored according to the maximum retention time, resulting in additional message storage fees.
2. In TDMQ for Apache Pulsar, message data is stored on the Bookie storage node of the BookKeeper cluster in the form of ledger. Even if deletion after consumption is configured, when the ledger is turned on, the async cleaner will not clear the message data. If some messages are not consumed for a long time, other messages in the same ledger may keep consuming the storage space, resulting in additional message storage fees.
Partition topic resource usage price
TDMQ for Apache Pulsar virtual cluster adopts linear billing for partition topic resource usage. Partition topic resource usage fees = number of partition topics * partition topic resource usage unit price.
The number of partition topics in TDMQ for Apache Pulsar refers to the sum of all partitions of all topics; that is, if there are two three-partition topics, the number of partition topics is 2 * 3 = 6.
The unit price of partition topic resource usage (USD/piece/day) is as shown below:
|
Unit price (USD/piece/day) | 0.0251 | 0.0327 | 0.0402 |
Note:
The partition topic resource usage fees in TDMQ for Apache Pulsar virtual cluster are charged by day; that is, a partition topic resource created at any time on a natural day will incur a full day's fees on the next natural day even if its actual usage time is less than 24 hours.
Free Tiers
TDMQ for Apache Pulsar offers certain free tiers to each root account for pay-as-you-go billable items in each region:
|
| | Accumulated monthly by region |
| | Accumulated monthly by region |
| | Accumulated monthly by region |
The free tiers will be used first to deduct the cumulative usage of all clusters in each region under each root account, and they are shared between different clusters in the same region.