Tiered Storage Limitations

This document describes the current limitations and operational impact of Infrequent Access (IA) storage, including feature constraints, cold-read throttling, tool compatibility, and query performance uncertainty.

Feature limitations

Access throttling constraints

Since shared physical clusters have limited object storage bandwidth, IA cold storage access must comply with the following limits:

If your business involves sustained heavy access to cold data, IA is not recommended; revert the table to Standard storage. To ensure system stability, hard throttling for cold data access will be added in a future technical release. For now, you must comply with the constraints above.

You can monitor single SQL cold data access volume via the IA Remote Read Segment Size panel in Cloud Console → Monitoring → Diagnosis → Slow Query → Coprocessor. To monitor IA cache behavior for the whole cluster, use the IA Cache Performance panels described in Tiered Storage Observability.

Impact on peripheral tools

Risk isolation mechanisms

After setting IA on a table, the system uses the following measures to isolate IA and non-IA tables:

Region level:

• IA tables/partitions occupy dedicated regions, triggering necessary splits
• Adjacent regions with different storage classes are restricted from merging, preventing hot/cold data mixing
• A single region is either entirely IA or entirely non-IA

Compute layer:

• Standard and IA tables have no isolation at the compute layer — TiDB does not have separate isolation strategies for the two table types

Storage layer:

• Cold read rate limiting

Emergency recovery methods

If issues arise with IA tables, you and the TiDB Cloud team can use the following methods:

IA local cache and query performance uncertainty

Tiered storage maintains a local IA data cache (managed by IaManager) to accelerate repeated access to recently accessed cold data. However, the following key facts should be understood:

• Cache capacity is adjustable, but cache behavior is still system-managed: You can select an IA cache level in the Cloud Console to control how much IA data is cached on local disks. Eviction policies remain managed by the system: you cannot specify which data stays in the cache, and the cache level applies to the underlying TiKV physical cluster rather than to an individual logical instance, table, or partition. Cache hit rates depend on actual access patterns: concentrated access can exceed 95%, while scattered access may fall below 95%.
• IA query response time is non-deterministic: When a query hits the local cache, performance is close to Standard tables. However, when data must be loaded from remote object storage (cache miss), each remote request adds approximately 500ms~2s of latency. A single SQL execution may involve multiple remote loads, causing latency to accumulate. Therefore, IA table query response times are not as predictable as Standard tables — the business side should plan accordingly.
• Recommended: use partitioned tables to precisely control cold data scope: Use partitioned tables, setting only confirmed low-frequency historical partitions to IA while keeping active partitions as Standard. This limits the cache uncertainty to a well-defined data range, rather than exposing the entire table's query performance to cache miss risk.
• Increasing cache space means increasing cost: A higher cache level keeps more IA data on local disks, which consumes more local disk and TiKV resources. On TiDB Cloud Premium, a higher cache level increases the billed IA storage amount. On TiDB Cloud BYOC, the additional resources are provisioned in your own cloud account, are billed by your cloud provider, and take some time to provision. Balance cold-read performance against cost according to your business needs.

In short: IA storage reduces storage costs at the expense of less predictable query performance—this is an inherent design trade-off. Use partitioned tables to precisely define which data is cold and limit the impact to that data. If your business requires predictable query response times, keep latency-sensitive data in Standard storage.