Billing covers data storage, read throughput, and outbound public traffic.
Search index is billed independently of the data table. For unit prices, see Tablestore pricing page.
Data storage fee
Search index stores data independently. Billing is based on the compressed index size in GB, calculated hourly.
Different index types consume system resources at very different rates, so storage is not billed by the source table's raw data size.
Billing method
Pay-as-you-go .
Formula
Size is the compressed index size.
Compute fee
Search index queries are billed by read throughput, which has two components: reserved read throughput and pay-as-you-go read throughput. Read throughput is measured in Capacity Units (CUs).
Reserved read throughput
Tablestore automatically sets reserved read throughput based on the index size and row count, measured in CUs. The reserved read throughput fee covers the following resource usage:
Reading data from the source table during index creation, which consumes read throughput.
Write throughput consumed by index creation, including tokenization. This is included in the reserved read throughput fee.
Memory used to keep parts of the index resident for query performance. This memory usage is included in the reserved read throughput.
Queries that consume read throughput within the reserved amount are billed at the reserved rate. For example, with reserved read throughput of 10,000 CUs and each query returning 10 rows under 4 KB, sustained traffic below 1,000 QPS stays within the reserved quota and incurs no extra charge.
Reserved read throughput scales with both index size and row count: 1 GB requires 10 CUs, and 2 million rows also require 10 CUs. When the two calculations differ, the larger value applies.
Reserved read throughput is recalculated hourly and does not update in real time.
When the index size is less than 200 MB and the row count is less than 400,000, the reserved read throughput is 20 CUs.
When the index size is at least 200 MB or the row count is at least 400,000, the minimum reserved read throughput is 100 CUs.
Pay-as-you-go read throughput
When actual read throughput exceeds the reserved amount, the excess is billed as pay-as-you-go read throughput, measured in CUs.
Billing method
Pay-as-you-go or resource plan.
Formula
Index reserved read CU:
Query read CU:
Size: compressed index size.Rows: total row count in the index, excluding child rows of nested types.ReturnRowSize: size of each returned row.ReturnRowCount: number of returned rows.
Billing examples
Prices in the following table are examples. For current rates, see the Tablestore pricing page.
When actual read throughput exceeds the reserved amount, the excess is billed as pay-as-you-go read throughput.
Index size | Index row count | Cost calculation |
8 GB | 9 million rows |
|
100 GB | 300 million rows |
|
Outbound public traffic fee
Reading search index data over the public network incurs outbound public traffic charges, measured in GB.
Billing method
Pay-as-you-go.
Formula
Outbound public traffic (GB) × unit price per GB.
FAQ
Why does using a search index on a Capacity instance incur storage and read/write fees at High-performance instance rates?
To guarantee performance, search index data is stored on high-performance media and is billed at High-performance instance rates.
How do I view search index usage data?
View the storage size, row count, and other usage data of a search index in the Tablestore console. For details, see Monitoring and alerts.
In CU mode, why does using a search index incur reserved read CUs?
Tablestore automatically sets reserved read throughput based on index size and row count to cover resource usage from index building, tokenization, and memory residency. For details, see the reserved read throughput description under CU mode.
In CU mode, can the reserved read CUs of a search index be adjusted?
No. Reserved read CUs scale with index size and row count and cover index building and memory residency. To reduce this cost, shrink the index size or trim the row count.
Does the reserved read throughput update in real time?
No. Tablestore recalculates the reserved read throughput hourly based on the index size.