enabling-data-tiering.md

Error in user YAML: (<unknown>): did not find expected node content while parsing a flow node at line 9 column 22

---
title: Manage storage and tiering
excerpt: Configure high-performance and low-cost object storage tiers in Tiger Console. With automated data tiering policies, you get a set it and forget it tool to cut storage costs
products: [cloud]
price_plans: [performance, scale, enterprise]
keywords: [tiered storage]
tags: [storage, data management]
cloud_ui:
    path:
        - [services, :serviceId, overview]
---

import TieredStorageBilling from "versionContent/_partials/_tiered-storage-billing.mdx";

Manage storage and tiering

The tiered storage architecture in $CLOUD_LONG includes a high-performance storage tier and a low-cost object storage tier:

• You use high-performance storage to store and query frequently accessed data.

• You use low-cost object storage to cut costs by migrating rarely used data from the high-performance storage. After you enable tiered storage, you then either create automated tiering policies or manually tier and untier data.

You can query the data on the object storage tier, but you cannot modify it. Make sure that you are not tiering data that needs to be actively modified.

High-performance storage tier

By default, $CLOUD_LONG stores your $SERVICE_SHORT data in the standard high-performance storage. This storage tier comes in the standard and enhanced types. Enhanced storage is available under the Enterprise $PRICING_PLAN only.

Standard high-performance storage

This storage type gives you up to 16 TB of storage and is available under all $PRICING_PLANs. You change the IOPS value to better suit your needs in $CONSOLE:

1. In $CONSOLE, select your $SERVICE_SHORT, then click Operations > Compute and storage

   By default, the type of high-performance storage is set to Standard.

2. Select the IOPS value in the I/O boost dropdown

   • Under the $PERFORMANCE $PRICING_PLAN, IOPS is set to 3,000 - 5,000 autoscale and cannot be changed.
   • Under the $SCALE and $ENTERPRISE $PRICING_PLANs, IOPS is set to 5,000 - 8,000 autoscale and can be upgraded to 16,000 IOPS.

   

3. Click Apply

Enhanced high-performance storage

<Availability products={['cloud']} price_plans={['enterprise']} />

This storage type gives you up to 64 TB and 32,000 IOPS, and is available under the $ENTERPRISE $PRICING_PLAN. To get enhanced storage:

1. In $CONSOLE, select your $SERVICE_SHORT, then click Operations > Compute and storage

2. Select Enhanced in the Storage type dropdown

   

   The enhanced storage is currently not available in sa-east-1.

3. Select the IOPS value in the I/O boost dropdown

   Select between 8,000, 16,000, 24,000, and 32,0000 IOPS. The value that you can apply depends on the number of CPUs in your $SERVICE_SHORT. $CONSOLE notifies you if your selected IOPS requires increasing the number of CPUs. To increase IOPS to 64,000, click Contact us and we will be in touch to confirm the details.

   

4. Click Apply

You change from enhanced storage to standard in the same way. If you are using over 16 TB of enhanced storage, changing back to standard is not available until you shrink your data to be under 16 TB. You can make changes to the storage type and $IO_BOOST settings without any downtime. Wait at least 6 hours to attempt another change.

Low-cost object storage tier

<Availability products={['cloud']} price_plans={['enterprise', 'scale']} />

You enable the low-cost object storage tier in $CONSOLE and then tier the data with policies or manually.

Enable tiered storage

You enable tiered storage from the Overview tab in $CONSOLE.

1. In $CONSOLE, select the $SERVICE_SHORT to modify

2. In Explorer, click Storage configuration > Tiering storage, then click Enable tiered storage

   

   Once enabled, you can proceed to tier data manually or set up tiering policies. When tiered storage is enabled, you see the amount of data in the tiered object storage.

Data tiering is available in Scale and Enterprise pricing plans only.

Automate tiering with policies

A tiering policy automatically moves any chunks that only contain data older than the move_after threshold to the object storage tier. This works similarly to a data retention policy, but chunks are moved rather than deleted.

A tiering policy schedules a job that runs periodically to asynchronously migrate eligible chunks to object storage. Chunks are considered tiered once they appear in the timescaledb_osm.tiered_chunks view.

You can add tiering policies to hypertables, including continuous aggregates. To manage tiering policies, connect to your service and run the queries below in the data mode, the SQL editor, or using psql.

Add a tiering policy

To add a tiering policy, call add_tiering_policy:

SELECT add_tiering_policy(hypertable REGCLASS, move_after INTERVAL, if_not_exists BOOL = false);

For example, to tier chunks that are more than three days old in the example hypertable:

SELECT add_tiering_policy('example', INTERVAL '3 days');

By default, a tiering policy runs hourly on your database. To change this interval, call alter_job.

Remove a tiering policy

To remove an existing tiering policy, call remove_tiering_policy:

SELECT remove_tiering_policy(hypertable REGCLASS, if_exists BOOL = false);

For example, to remove the tiering policy from the example hypertable:

SELECT remove_tiering_policy('example');

If you remove a tiering policy, the remaining scheduled chunks are not tiered. However, chunks in tiered storage are not untiered. You untier chunks manually to local storage.

Manually tier and untier chunks

If tiering policies do not meet your current needs, you can tier and untier chunks manually. To do so, connect to your $SERVICE_SHORT and run the queries below in the data mode, the SQL editor, or using psql.

Tier chunks

Tiering a chunk is an asynchronous process that schedules the chunk to be tiered. In the following example, you tier chunks older than three days in the example hypertable. You then list the tiered chunks.

1. Select all chunks in example that are older than three days:

   SELECT show_chunks('example', older_than => INTERVAL '3 days');

   This returns a list of chunks. Take a note of the chunk names:

   _timescaledb_internal._hyper_1_1_chunk
   _timescaledb_internal._hyper_1_2_chunk

2. Call tier_chunk to manually tier each chunk:

   SELECT tier_chunk('_timescaledb_internal._hyper_1_1_chunk');

3. Repeat for all chunks you want to tier.

   Tiering a chunk schedules it for migration to the object storage tier, but the migration won't happen immediately. Chunks are tiered one at a time in order to minimize database resource consumption. A chunk is marked as migrated and deleted from the standard storage only after it has been durably stored in the object storage tier. You can continue to query a chunk during migration.

4. To see which chunks are tiered into the object storage tier, use the tiered_chunks informational view:

   SELECT * FROM timescaledb_osm.tiered_chunks;

To see which chunks are scheduled for tiering either by policy or by a manual call, but have not yet been tiered, use this view:

SELECT * FROM timescaledb_osm.chunks_queued_for_tiering ;

Untier chunks

To update data in a tiered chunk, move it back to the standard high-performance storage tier in $CLOUD_LONG. Untiering chunks is a synchronous process. Chunks are renamed when the data is untiered.

To untier a chunk, call the untier_chunk stored procedure.

1. Check which chunks are currently tiered:

   SELECT * FROM timescaledb_osm.tiered_chunks ;

   Sample output:

    hypertable_schema | hypertable_name |    chunk_name    |      range_start       |       range_end
   -------------------+-----------------+------------------+------------------------+------------------------
   public            | sample          | _hyper_1_1_chunk | 2023-02-16 00:00:00+00 | 2023-02-23 00:00:00+00
   (1 row)

2. Call untier_chunk:

   CALL untier_chunk('_hyper_1_1_chunk');

3. See the details of the chunk with timescaledb_information.chunks:

   SELECT * FROM timescaledb_information.chunks;

   Sample output:

   -[ RECORD 1 ]----------+-------------------------
   hypertable_schema      | public
   hypertable_name        | sample
   chunk_schema           | _timescaledb_internal
   chunk_name             | _hyper_1_4_chunk
   primary_dimension      | ts
   primary_dimension_type | timestamp with time zone
   range_start            | 2023-02-16 00:00:00+00
   range_end              | 2020-03-23 00:00:00+00
   range_start_integer    |
   range_end_integer      |
   is_compressed          | f
   chunk_tablespace       |
   data_nodes             |

Disable tiering

If you no longer want to use tiered storage for a particular hypertable, drop the associated metadata by calling disable_tiering.

1. To drop all tiering policies associated with a table, call remove_tiering_policy.

2. Make sure that there is no tiered data associated with this hypertable:

   1. List the tiered chunks associated with this hypertable:

      select * from timescaledb_osm.tiered_chunks 

   2. If you have any tiered chunks, either untier this data, or drop these chunks from tiered storage.

3. Use disable_tiering to drop all tiering-related metadata for the hypertable:

   select disable_tiering('my_hypertable_name');

4. Verify that tiering has been disabled by listing the hypertables that have tiering enabled:

   select * from timescaledb_osm.tiered_hypertables;