CU mode (formerly pay-as-you-go mode) is ideal for services with large, unpredictable changes in workload.Tablestore bills you on a per-instance basis.The billable items for CU mode (formerly pay-as-you-go mode) are read throughput, write throughput, data storage, cross-region replication traffic, and outbound internet traffic. Using core features such as search index, secondary index, SQL query, time series model, multiple versions, lifecycle management, Tunnel Service, global tables, or data migration and synchronization incurs fees for data reads, writes, and storage.
Pricing
For detailed pricing, see the Tablestore pricing page.
You can use the pricing calculator to estimate your product costs.
Basic billing
Billing components
Tablestore provides two instance types: storage-optimized and high-performance. The billing components for different instance types are shown in the following figure.

Billable items
In CU mode (formerly pay-as-you-go mode), the fees for a Tablestore instance include read throughput, write throughput, data storage, cross-region replication traffic, and outbound internet traffic.
|
Billable item |
Billing method |
Billing rules |
|
|
Reserved read throughput |
|
The sum of the reserved read throughput for all tables in an instance is billed hourly based on the average value of the hourly reserved read throughput in a billing cycle. The unit is CU. Note
Only high-performance instances support reserved read throughput. |
|
|
Pay-as-you-go read throughput |
|
The actual read throughput consumed per second. Tablestore bills you for the sum of the pay-as-you-go read throughput for all tables in the instance within a billing cycle. The unit is CU. |
|
|
Reserved write throughput |
|
The sum of reserved write throughput for all tables in an instance. Billing is hourly based on the average reserved write throughput per hour in a billing cycle. The unit is CU. Note
Only high-performance instances support reserved write throughput. |
|
|
Pay-as-you-go write throughput |
|
The actual write throughput consumed per second. Tablestore bills you for the sum of the pay-as-you-go write throughput for all tables in the instance within a billing cycle. The unit is CU. |
|
|
Note
To reduce storage costs for large data volumes, purchase a resource plan. |
High-performance storage |
|
Suitable for latency-sensitive online services with millisecond-level latency for a single request. Dynamically scales based on actual usage. Billing is hourly based on the average total data volume per hour in a billing cycle. The unit is GB. |
|
Storage-optimized storage |
|
Ideal for services that are not sensitive to read latency and require large storage space. Dynamically scales based on actual usage. Billing is hourly based on the average total data volume per hour in a billing cycle. The unit is GB. |
|
|
Cross-region replication traffic |
Pay-as-you-go |
When using global tables, cross-region data traffic is generated when data is asynchronously replicated to replica tables. Billing is based on the actual volume of synchronized data. The unit is GB. Important
The cross-region replication traffic fee for each replica is calculated separately. The fee is metered to the instance from which the data is pulled. |
|
|
Outbound internet traffic |
Pay-as-you-go |
Outbound internet traffic fees are generated when your application accesses Tablestore. These fees are mainly for the responses returned from Tablestore over HTTP. The formula is: Outbound internet traffic fee = Outbound internet traffic (GB) × Price per GB. Note
|
|
Billing for core features
Using core features such as search index, secondary index, SQL query, time series model, multiple versions, lifecycle management, Tunnel Service, global tables, or data migration and synchronization also incurs fees.
-
If you access Tablestore over the internet, you will incur outbound internet traffic fees.
-
SQL queries do not incur additional compute costs. However, operations involved in the query process, such as table scans and index queries, incur fees.
The billing rules for each feature are described in the following table.
|
Core feature |
Billing rules |
|
Search index |
The search index feature incurs fees for high-performance storage, reserved read throughput, and pay-as-you-go read throughput, regardless of the instance type. For more information, see Billing for search index. |
|
SQL query |
SQL queries do not incur additional compute costs. However, operations such as table scans and index queries that are performed during the data query process incur read and write throughput fees. For more information, see Billing for SQL query. |
|
Secondary index |
Billable items include index table data storage and index table read throughput. For more information, see Billing for secondary index. |
|
Time series model |
Billable items include data storage and pay-as-you-go read/write throughput. For more information, see Billing for time series model. |
|
Multiple data versions |
This feature incurs additional storage fees based on the version numbers and the data of each version. For more information, see Data storage. |
|
Lifecycle management |
Configuring lifecycle management to clean up data does not incur additional data cleanup fees. However, after you enable the lifecycle management feature, a timestamp is added to each attribute column as a version number, which results in additional storage usage. For more information, see Data storage. |
|
Tunnel Service |
Tunnel Service does not incur additional overhead. When you consume data from Tunnel Service, read throughput is incurred based on the actual data that is pulled. |
|
Global table |
Using global tables incurs fees for data reads and writes, data storage, and cross-region replication traffic for data synchronization between replicas. For more information, see Billing for global tables. |
|
Data synchronization and migration (using tools or other products) |
When you use migration tools or other products (such as DTS or Alibaba Cloud IoT Platform) to migrate and access Tablestore, you are billed for read and write throughput based on the specific read and write requests. |
|
Compute engine access (MaxCompute, Spark, Flink, etc.) |
When various compute engines access Tablestore, you are billed for read and write throughput based on the specific read and write requests. |
Billing examples
Scenario
Suppose that a user in the China (Hangzhou) region creates a high-performance instance and a storage-optimized instance in Tablestore. A table created in each instance has a stable read workload of 10,000 queries per second (QPS). Each read request is smaller than 4 KB, which is equivalent to 1 CU.
Analysis
The following table describes how to calculate the daily fees for the same table in different instances based on different reserved read throughput settings.
|
Instance type |
Reserved read throughput setting |
Fee calculation formula |
Fee (Unit: CNY) |
Description |
|
High-performance instance |
0 |
Pay-as-you-go read unit price × Pay-as-you-go read CUs |
10,000 × 86,400 / 10,000 × 0.01 = 864 |
If the reserved read throughput is 0, you are billed only for the total consumption of pay-as-you-go CUs. The number of pay-as-you-go read CUs consumed in one day is 10,000 × 86,400. |
|
4,000 |
Reserved read unit price × Reserved read CUs + Pay-as-you-go read unit price × Pay-as-you-go read CUs |
4,000 × 0.00056 × 24 + (10,000 - 4,000) × 86,400 / 10,000 × 0.01 = 572.16 |
If the reserved read throughput is greater than 0 and less than the table's QPS, the reserved throughput is billed based on the specified value. The portion that exceeds the reserved throughput is billed on a pay-as-you-go basis. The reserved read throughput fee is |
|
|
10,000 |
Reserved read unit price × Reserved read CUs |
10,000 × 0.00056 × 24 = 134.4 |
If the reserved read throughput is the same as the table's QPS, no pay-as-you-go CUs are consumed. You are billed only for the total amount of reserved CUs. |
|
|
Storage-optimized instance |
Not applicable |
Pay-as-you-go read unit price × Pay-as-you-go read CUs |
10,000 × 86,400 / 10,000 × 0.004 = 345.6 |
Storage-optimized instances do not support reserved read/write throughput. All read and write operations are billed based on pay-as-you-go read/write throughput. |
This shows that you can optimize your resource costs by effectively using reserved read/write throughput.
-
The preceding prices are for reference only. The actual prices on the console prevail.
-
Storage-optimized instances offer lower storage and data access costs and support millions of transactions per second (TPS) for writes, but their read performance is lower than that of high-performance instances.
-
The instance type (high-performance or storage-optimized) cannot be changed after the instance is created. You must create an instance of the type that best suits your business scenario.
FAQ
I use a storage-optimized instance. Why am I charged for reserved read throughput?
When you use the search index feature, Tablestore automatically sets a reserved read throughput based on the size of the index data. Therefore, if you use a search index in a storage-optimized instance, you also incur fees for reserved read throughput. For more information about billing for search index, see Billing for search index.
The reserved read throughput fee for a search index covers the following resource consumption:
-
When you create an index, data is first read from the data table. This operation consumes a specific amount of read throughput.
-
Creating an index consumes write throughput. The process may also involve tokenization, which leads to higher resource consumption. This cost is included in the reserved read throughput fee and is not billed separately.
-
To ensure index and query performance, parts of the index are pre-loaded and kept in memory, which consumes system memory resources. This cost is also included in the reserved read throughput fee.
What are the differences between VCU mode (formerly subscription mode) and CU mode (formerly pay-as-you-go mode)?
The main differences between VCU mode (formerly subscription mode) and CU mode (formerly pay-as-you-go mode) are as follows:
-
Compute
In VCU mode (formerly subscription mode), you can purchase reserved VCUs (4 cores and 16 GB of memory) on a subscription basis, or you can be billed for elastic capacity based on the actual compute consumption that is converted to VCUs. In CU mode (formerly pay-as-you-go mode), you are billed based on the actual compute consumption that is converted to CUs.
-
Storage
VCU mode (formerly subscription mode) supports billing based on different storage classes, while CU mode (formerly pay-as-you-go mode) is tied to the instance type.
-
Index
In VCU mode (formerly subscription mode), the storage component is billed separately, and the compute component is consumed from compute resources. In CU mode (formerly pay-as-you-go mode), billing is based on high-performance storage and reserved CUs.
For more information, see Differences between VCU mode and CU mode.
My data storage and read/write throughput usage is high. How can I reduce costs?
Tablestore provides resource plans to help you reduce costs. By purchasing a resource plan, you can receive discounts based on the resources and duration that you purchase. For more information about resource plans, see Resource plans.
Tablestore provides four types of resource plans: pay-as-you-go write CU plans, pay-as-you-go read CU plans, storage plans, and reserved CU plans. The types of resource plans that are supported vary based on the billing method. The following table provides details.
Resources that are not covered by a resource plan are billed on a pay-as-you-go basis by default. For example, if you purchase a Storage Plan and a Pay-as-you-go Write Plan, your storage usage and pay-as-you-go write throughput are deducted from the plans, while your read throughput is billed on a pay-as-you-go basis.
|
Type |
Applicable billing method |
Description |
|
Pay-as-you-go write CU plan |
CU mode (formerly pay-as-you-go mode) |
The total number of write CUs that can be used each month within the validity period. This is used to offset pay-as-you-go write throughput. For example, if you purchase a one-year pay-as-you-go write CU plan of 1 billion CUs, 1 billion pay-as-you-go write CUs are offset by the resource plan each month for one year. |
|
Pay-as-you-go read CU plan |
CU mode (formerly pay-as-you-go mode) |
The total number of read CUs that can be used each month within the validity period. This is used to offset pay-as-you-go read throughput and reserved read throughput. |
|
Storage plan |
|
The amount of storage that can be offset each hour within the validity period. |
|
Reserved CU plan |
CU mode (formerly pay-as-you-go mode) |
The amount of reserved read and write CUs that can be offset each hour within the validity period. This includes the reserved read throughput generated by search indexes. Note
The reserved read throughput of search indexes can be offset by reserved CU plans. |
If the pay-as-you-go cost for resources is higher than the cost of a resource plan for the same duration, you can purchase a resource plan to reduce your costs. For specific calculations, you can use the Tablestore Pricing page and the pricing calculator to estimate and compare costs.
If you use a high-performance instance or the search index feature, you can purchase a Reserved CU Plan to offset reserved read/write throughput costs.
Can I set a resource usage limit for a pay-as-you-go instance?
You cannot set an overall resource usage limit for a pay-as-you-go instance. You must manage usage at the application layer to prevent high costs that are caused by unusual traffic.
How do I view the read/write CU usage of an instance?
You can view the read/write CU usage of a Tablestore instance in the following ways.
-
View monitoring data in the Cloud Monitor console and using an SDK
-
Export metering data from the User Center. For more information, see Query usage.
How do I view the data size of tables in an instance?
You can view the data size of tables in an instance in the Tablestore console or the User Center.
-
Viewing in the Tablestore console
-
Log on to the Tablestore console.
-
In the top navigation bar, select a region.
-
On the Overview page, click the name of the target instance or click Instance Management in the Operation column.
-
On the Instance Details tab, in the Instance Basic Information section, view the table data size.
-
-
You can export metering data from the Fee Hub. For more information, see Usage Query.