Understand the core Tablestore concepts, including regions, instances, endpoints, and read/write throughput.
Regions
Tablestore is available in multiple regions worldwide. To reduce latency, select the region closest to your workloads. For cross-region disaster recovery, create instances in multiple regions. Specify the region ID when you configure an SDK, call an API operation, or use the Tablestore console. The following table lists all supported regions and their region IDs.
Public cloud
Area | Region | Region ID |
China | China (Hangzhou) | cn-hangzhou |
China (Shanghai) | cn-shanghai | |
China (Qingdao) | cn-qingdao | |
China (Beijing) | cn-beijing | |
China (Zhangjiakou) | cn-zhangjiakou | |
China (Hohhot) | cn-huhehaote | |
China (Ulanqab) | cn-wulanchabu | |
China (Shenzhen) | cn-shenzhen | |
China (Heyuan) | cn-heyuan | |
China (Guangzhou) | cn-guangzhou | |
China (Chengdu) | cn-chengdu | |
China (Zhongwei) | cn-zhongwei | |
China (Hong Kong) | cn-hongkong | |
Asia Pacific | Japan (Tokyo) | ap-northeast-1 |
South Korea (Seoul) | ap-northeast-2 | |
Singapore | ap-southeast-1 | |
Malaysia (Kuala Lumpur) | ap-southeast-3 | |
Indonesia (Jakarta) | ap-southeast-5 | |
Philippines (Manila) | ap-southeast-6 | |
Thailand (Bangkok) | ap-southeast-7 | |
Malaysia (Johor) | ap-southeast-8 | |
Europe and Americas | Germany (Frankfurt) | eu-central-1 |
UK (London) | eu-west-1 | |
France (Paris) | eu-west-2 | |
US (Silicon Valley) | us-west-1 | |
US (Virginia) | us-east-1 | |
Middle East | UAE (Dubai) | me-east-1 |
Finance Cloud
Region | Region ID |
China East 1 Finance Cloud | cn-hangzhou-finance |
China East 2 Finance Cloud | cn-shanghai-finance-1 |
China South 1 Finance Cloud | cn-shenzhen-finance-1 |
China Gov Cloud
Region | Region ID |
China North 2 China Gov Cloud 1 | cn-north-2-gov-1 |
Instances
An instance is the basic unit for using and managing Tablestore. Each instance works as a database. Tablestore performs access control and resource metering at the instance level. After you activate Tablestore, create an instance in the Tablestore console. You can then create tables and manage data within that instance.
Each Alibaba Cloud account can create up to 10 instances, and each instance can contain up to 64 tables (including data tables, secondary index tables, and time series tables). To increase these quotas, submit a ticket or join the Tablestore technical support group 36165029092.
Billing modes
Tablestore offers two billing modes: VCU mode (formerly reserved mode) and CU mode (formerly pay-as-you-go mode). The following table describes the key differences. For more information, see Billing overview.
Item | VCU mode (formerly reserved mode) | CU mode (formerly pay-as-you-go mode) |
Billing | Billed by computing capacity (VCU). 1 VCU equals 4 vCPUs and 16 GiB of memory. Supports reserved VCUs (subscription) and elastic capacity (auto-scales in 0.1 VCU increments, billed hourly). You can use both together. | Billed by real-time read/write throughput (CU). You are charged based on actual read/write capacity units and storage consumed, with no upfront capacity planning required. |
Resource control | Elastic capacity upper limits are configurable. You can set or disable elastic capacity limits to control overall resource consumption and prevent unexpected charges from traffic spikes. | No built-in resource consumption limits. Implement application-level controls to prevent unexpected charges from traffic spikes. |
Use cases | Best for cost-sensitive workloads. Purchase reserved VCUs for baseline capacity and use elastic capacity to handle traffic bursts. | Best for workloads with unpredictable traffic patterns. Pay only for actual usage, with elastic capacity to handle traffic bursts. |
Instance types
Tablestore offers two billing modes: VCU mode (formerly reserved mode) and CU mode (formerly pay-as-you-go mode). VCU mode has a single instance type. CU mode supports two instance types: High-performance and Capacity. Each instance type can handle petabyte-scale data per table. Select the type that best fits your use case and budget. For details, see the following tables.
The instance type cannot be changed after creation. Choose carefully.
Regardless of the instance type, using search indexes incurs charges for high-performance storage, reserved read throughput, and on-demand read throughput. For more information, see Billable items of search indexes.
Regardless of the instance type, when you use the time series model, on-demand read/write throughput for time series data is billed at the Capacity rate, on-demand read/write throughput for time series metadata is billed at the High-performance rate, and time series metadata storage is billed at the High-performance storage rate. For more information, see Billable items of the TimeSeries model.
VCU mode
Storage type | High-performance storage | Capacity storage | |
Use cases | Latency-sensitive workloads that require ultra-low read latency and high stability. | Write-heavy workloads with low read frequency that are not sensitive to read latency, or large-scale data storage at reduced cost. | |
Billing components |
|
| |
Performance | Read | High | Medium |
Write | High | High | |
Concurrency | High | Medium | |
CU mode
Instance type | High-performance | Capacity | |
Use cases | Online workloads that require high concurrency and ultra-low read/write latency. | Offline workloads that require lower-cost storage. Not suitable for latency-sensitive online workloads. | |
Billing components |
|
| |
Performance | Read | High | Medium |
Write | High | High | |
Concurrency | High | Medium | |
Regional availability
The following tables list the regions that support each instance type and storage type.
VCU mode
Storage type | Area | Supported regions |
High-performance storage | China | China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Zhongwei), China (Hong Kong) |
Asia Pacific | Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok) | |
Europe and Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia) | |
Capacity storage | China | China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), China (Hong Kong) |
Asia Pacific | Japan (Tokyo), Malaysia (Kuala Lumpur), Indonesia (Jakarta) | |
Europe and Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia) Note The US (Silicon Valley) region does not support new purchases. | |
Middle East | UAE (Dubai) |
CU mode
Instance type | Area | Supported regions |
High-performance | China | China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Zhongwei), China (Hong Kong) |
Asia Pacific | South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Malaysia (Johor) | |
Europe and Americas | Germany (Frankfurt), UK (London), France (Paris), US (Silicon Valley), US (Virginia) | |
Middle East | Saudi Arabia (Riyadh) | |
Capacity | China | China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), China (Hong Kong) |
Asia Pacific | Japan (Tokyo), Malaysia (Kuala Lumpur), Indonesia (Jakarta) | |
Europe and Americas | Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia) Note The US (Silicon Valley) region does not support new purchases. | |
Middle East | UAE (Dubai) |
Endpoints
Endpoint types
Each Tablestore instance has a unique endpoint. Four endpoint types are available: public, dual-stack public, VPC, and classic network. Select the endpoint type based on your network environment.
Accessing Tablestore over the Internet incurs outbound traffic charges. For more information, see Billing overview.
Public
Use the public endpoint to access Tablestore over the Internet. Endpoint format:
https://instanceName.RegionID.ots.aliyuncs.comVPC
Use the VPC endpoint to access Tablestore from a virtual private cloud. Endpoint format:
https://instanceName.RegionID.vpc.tablestore.aliyuncs.comClassic network
Use the classic network endpoint to access Tablestore from an ECS instance in the same region over the classic network. This reduces latency and avoids Internet traffic charges. Endpoint format:
https://instanceName.RegionID.ots-internal.aliyuncs.comDual-stack public
Use the dual-stack public endpoint to access Tablestore over the Internet with IPv4 and IPv6 support. Endpoint format:
https://instanceName.RegionID.tablestore.aliyuncs.comDual-stack public endpoints are available only in the following regions: China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), and China (Hong Kong).
Get an endpoint
Log on to Tablestore console. You can switch the region and resource group at the top of the page.
On the Overview, click the instance name or Instances. Select the appropriate Instance Access URL.
Access scenario
Endpoint to use
Over the Internet
Use the Internet, or the Dual-stack public endpoint, depending on the IP protocol that your client supports.
Internet access has higher latency. Use VPC or classic network access when possible.
ImportantIf your client uses only IPv6, use the Dual-stack public endpoint.
If your client does not support IPv6, use either the Internet or the Dual-stack public endpoint.
From a VPC
Use the VPC endpoint.
From the classic network
Use the Classic Network endpoint.
NoteFor more information about VPCs and the classic network, see Network types.
Read/write throughput
Read and write throughput is measured in capacity units (CUs). A CU is the minimum billing unit for data read and write operations. Each API read or write operation on a data table consumes the corresponding read or write CUs.
CU calculation rules
One read CU represents reading one row of up to 4 KB from a data table.
One write CU represents writing one row of up to 4 KB to a data table.
Data that is smaller than 4 KB or not a multiple of 4 KB is rounded up to the nearest 4 KB. For example, writing 7.6 KB of data consumes 2 write CUs, and reading 0.1 KB of data consumes 1 read CU.
On-demand read/write throughput
On-demand read/write throughput is the actual throughput consumed per second that exceeds the reserved read/write throughput. The measurement interval is one second. Within each hour, Tablestore calculates the average reserved read/write throughput and the cumulative on-demand read/write throughput as the actual throughput consumed.
On-demand throughput is priced higher than reserved throughput because Tablestore must provision sufficient capacity for unpredictable traffic peaks. To reduce costs, set appropriate reserved read/write throughput.
Because Tablestore cannot accurately estimate the resources to reserve for on-demand throughput, the service may return the OTSCapacityUnitExhausted error when a single partition key consumes more than 10,000 CU per second. Use exponential backoff to reduce the request rate to the data table.
Reserved read/write throughput
Reserved read/write throughput is a property of data tables in high-performance instances under CU mode (formerly on-demand mode). You can specify the reserved read/write throughput when you create a data table.
When you use search indexes, Tablestore automatically sets a reserved read throughput based on the index data size. For more information, see Billable items of search indexes. The reserved read throughput of search indexes cannot be adjusted. To reduce this cost, optimize the index size or the number of rows.
If the reserved read/write throughput is greater than 0, Tablestore allocates and reserves the corresponding resources for the data table. Access that does not exceed the reserved throughput per second is billed at the reserved throughput rate.
If the reserved read/write throughput is set to 0, Tablestore does not allocate or reserve resources for the data table.
NoteA non-existent data table is treated as having 0 reserved read/write throughput. Accessing a non-existent data table consumes 1 on-demand read CU or 1 on-demand write CU depending on the operation type.
The unit price of reserved throughput is lower than that of on-demand throughput. To reduce costs, set an appropriate reserved throughput level. For example, before importing a large amount of data, set a high reserved write throughput to lower the write cost. After the import is complete, reduce the reserved throughput.
Usage limits
Data tables in capacity instances do not support reserved read/write throughput.
Reserved read/write throughput greater than 0 incurs charges even without read or write requests. Tablestore limits reserved read throughput and reserved write throughput to a maximum of 100,000 each per data table. If a data table requires reserved read/write throughput greater than 100,000, submit a ticket or join the Tablestore technical support group 36165029092 to contact technical support.
Reserved read/write throughput update rules
Use the UpdateTable operation to modify the reserved read/write throughput of a table. The following rules apply:
Within each calendar day (from UTC 00:00:00 to 00:00:00 the next day, or from 08:00 to 08:00 the next day in UTC+8), you can adjust the reserved throughput an unlimited number of times. The interval between two consecutive updates to the same data table must be greater than 1 minute.
The adjusted reserved read/write throughput takes effect within 1 minute.
Calculation example
Assume that the reserved read throughput of a data table is set to 100 CU. The following access pattern occurs over 3 consecutive seconds:
T0: Read operations consume 120 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 20 CU.
T1: Read operations consume 95 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 0 CU.
T2: Read operations consume 110 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 10 CU.
From T0 to T2, the total read throughput consumed is 100 CU of reserved read throughput and 30 CU of on-demand read throughput.