Skip to content

Manage storage and tiering

Configure high-performance and low-cost object storage tiers in Tiger Console

Tiering splits hot data on fast local volumes from cold data in cheaper object storage. Tiger Cloud implements that as a high-performance tier plus a low-cost object storage tier:

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.

For low-cost storage, Tiger Data charges for data tiered based on its original uncompressed size in the high-performance storage tier. There are no additional expenses, such as data transfer or compute.

By default, Tiger Cloud stores your service 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.

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 Tiger Console:

  1. Select your service

    In Tiger Console, select your service, then click Operations > Compute and storage.

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

  2. Select the IOPS value

    Select the IOPS value in the I/O boost dropdown:

    Default high-performance storage in Tiger Console

    The autoscaled IOPS value depends on your provisioned storage and pricing plan:

    Storage sizePerformance plan IOPSScale/Enterprise plan IOPS
    Under 500 GBUp to 3,000Up to 5,000
    500 GB – 1,000 GBUp to 4,000Up to 6,000
    1,000 GB – 1,500 GBUp to 5,000Up to 7,000
    Above 1,500 GBUp to 5,000Up to 8,000
  3. Click Apply
Note

Enhanced high-performance storage is available on the Enterprise pricing plan.

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. Select your service

    In Tiger Console, select your service, then click Operations > Compute and storage.

  2. Select Enhanced storage type

    Select Enhanced in the Storage type dropdown.

    Enabling enhanced storage in Tiger Console
    Note

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

  3. Select the IOPS value

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

    Select between 8,000, 16,000, 24,000, and 32,000 IOPS. The value that you can apply depends on the number of CPUs in your service. Tiger 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.

    Setting I/O boost in Tiger Console
  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 I/O boost settings without any downtime. Wait at least 6 hours to attempt another change.

Note

Low-cost tiered storage is available on Scale and Enterprise pricing plans.

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

You enable tiered storage from the Overview tab in Tiger Console.

  1. Select your service

    In Tiger Console, select the service to modify.

  2. Enable tiered storage

    In Explorer, click Data Tiering > then click Enable tiered storage.

    Enabling tiered storage in Tiger Console

    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.

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, via Console UI or an SQL editor.

To add a tiering policy, connect to your service and 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.

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.

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

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 old chunks

    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:

    _timescaledb_internal._hyper_1_1_chunk
    _timescaledb_internal._hyper_1_2_chunk
  2. Tier each chunk
    SELECT tier_chunk('_timescaledb_internal._hyper_1_1_chunk');

    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 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.

  3. View tiered chunks
    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:

SELECT * FROM timescaledb_osm.chunks_queued_for_tiering;

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

  1. Check which chunks are 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. Verify the chunk details
    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 |

To drop tiered data, call DROP TABLE on the corresponding hypertable. This removes the hypertable and all its associated data from the high-performance and low-cost storage.

Warning

Contact Tiger Data support if you are disabling tiering when moving from Scale to Performance pricing plan.

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

  1. Remove tiering policies

    Drop all tiering policies by calling remove_tiering_policy.

  2. Check for tiered data

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

    1. List the tiered chunks:

      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. Disable tiering
    SELECT disable_tiering('my_hypertable_name');
  4. Verify tiering is disabled
    SELECT * FROM timescaledb_osm.tiered_hypertables;