Setup hypercore

Reduce your chunk size by up to 98% and speed up your queries by automatically converting data between the rowstore and columnstore

is the hybrid row-columnar storage engine in used by s. Traditional databases force a trade-off between fast inserts (row-based storage) and efficient analytics (columnar storage). eliminates this trade-off, allowing real-time analytics without sacrificing transactional capabilities.

dynamically stores data in the most efficient format for its lifecycle:

• Row-based storage for recent data: the most recent chunk (and possibly more) is always stored in the , ensuring fast inserts, updates, and low-latency single record queries. Additionally, row-based storage is used as a writethrough for inserts and updates to columnar storage.
• Columnar storage for analytical performance: chunks are automatically compressed into the , optimizing storage efficiency and accelerating analytical queries.

Unlike traditional columnar databases, allows data to be inserted or modified at any stage, making it a flexible solution for both high-ingest transactional workloads and real-time analytics—within a single database.

When you convert s from the to the , multiple records are grouped into a single row. The columns of this row hold an array-like structure that stores all the data. For example, data in the following chunk:

Timestamp	Device ID	Device Type	CPU	Disk IO
12:00:01	A	SSD	70.11	13.4
12:00:01	B	HDD	69.70	20.5
12:00:02	A	SSD	70.12	13.2
12:00:02	B	HDD	69.69	23.4
12:00:03	A	SSD	70.14	13.0
12:00:03	B	HDD	69.70	25.2

Is converted and compressed into arrays in a row in the :

Timestamp	Device ID	Device Type	CPU	Disk IO
[12:00:01, 12:00:01, 12:00:02, 12:00:02, 12:00:03, 12:00:03]	[A, B, A, B, A, B]	[SSD, HDD, SSD, HDD, SSD, HDD]	[70.11, 69.70, 70.12, 69.69, 70.14, 69.70]	[13.4, 20.5, 13.2, 23.4, 13.0, 25.2]

Because a single row takes up less disk space, you can reduce your chunk size by up to 98%, and can also speed up your queries. This saves on storage costs, and keeps your queries operating at lightning speed.

For an in-depth explanation of how s and work, see the Data model.

This page shows you how to get the best results when you set a policy to automatically convert s in a from the to the .

Prerequisites

To follow the steps on this page:

• Create a target with Real-time analytics enabled.

  You need your connection details. This procedure also works for .

The code samples in this page use the crypto_sample.zip data from this key features tutorial.

Optimize your data with columnstore policies

The following figure shows the workflow to follow when you setup .

The compression ratio and query performance of data in the is dependent on the order and structure of your data. Rows that change over a dimension should be close to each other. With time-series data, you orderby the time dimension. For example, Timestamp:

Timestamp	Device ID	Device Type	CPU	Disk IO
12:00:01	A	SSD	70.11	13.4

This ensures that records are compressed and accessed in the same order. However, you would always have to access the data using the time dimension, then filter all the rows using other criteria. To make your queries more efficient, you segment your data based on the following:

• The way you want to access it. For example, to rapidly access data about a single device, you segmentby the Device ID column. This enables you to run much faster analytical queries on data in the .
• The compression rate you want to achieve. The lower the cardinality of the segmentby column, the better compression results you get.

When converts a to the , it automatically creates a different schema for your data. It also creates and uses custom indexes to incorporate the segmentby and orderby parameters when you write to and read from the .

To set up your hypercore automation:

1. Connect to your service

   In Tiger Console open an SQL editor. You can also connect to your service using psql.

2. Enable columnstore on a hypertable

   For efficient queries, remember to segmentby the column you will use most often to filter your data. For example:

   • Hypertables:

     Use CREATE TABLE for a hypertable

     CREATE TABLE crypto_ticks (
       "time" TIMESTAMPTZ,
       symbol TEXT,
       price DOUBLE PRECISION,
       day_volume NUMERIC
     ) WITH (
       timescaledb.hypertable,
       timescaledb.segmentby='symbol',
       timescaledb.orderby='time DESC'
     );
     

     When you create a using CREATE TABLE ... WITH ..., the default partitioning column is automatically the first column with a timestamp data type. Also, creates a columnstore policy that automatically converts your data to the , after an interval equal to the value of the chunk_interval, defined through compress_after in the policy. This columnar format enables fast scanning and aggregation, optimizing performance for analytical workloads while also saving significant storage space. In the conversion, s are compressed by up to 98%, and organized for efficient, large-scale queries.

     You can customize this policy later using alter_job. However, to change after or created_before, the compression settings, or the the policy is acting on, you must remove the columnstore policy and add a new one.

     You can also manually convert s in a to the .

   • Continuous aggregates

     1. Use ALTER MATERIALIZED VIEW for a continuous aggregate:

        ALTER MATERIALIZED VIEW assets_candlestick_daily SET (
          timescaledb.enable_columnstore = true,
          timescaledb.segmentby = 'symbol'
        );
        

        Before you say “huh”, a is a specialized .

     2. Add a policy to convert s to the at a specific time interval:

        Create a columnstore_policy that automatically converts s in a to the at a specific time interval. For example:

        CALL add_columnstore_policy('assets_candlestick_daily', after => INTERVAL '1d');
        

   is optimized for fast updates on compressed data in the . To modify data in the , use standard SQL.

3. Check the columnstore policy

   1. View your data space saving:

      When you convert data to the , as well as being optimized for analytics, it is compressed by more than 90%. This helps you save on storage costs and keeps your queries operating at lightning speed. To see the amount of space saved:

      SELECT
        pg_size_pretty(before_compression_total_bytes) AS before,
        pg_size_pretty(after_compression_total_bytes) AS after
      FROM hypertable_columnstore_stats('crypto_ticks');
      

      You see something like:

      before	after
      194 MB	24 MB

   2. View the policies that you set or the policies that already exist:

      SELECT * FROM timescaledb_information.jobs
      WHERE proc_name='policy_compression';
      

      See timescaledb_information.jobs.

4. Pause a columnstore policy

   SELECT * FROM timescaledb_information.jobs WHERE
     proc_name = 'policy_compression' AND relname = 'crypto_ticks';
   
   -- Select the JOB_ID from the results, then use it in the next command
   
   SELECT alter_job(<JOB_ID>, scheduled => false);
   

   See alter_job.

5. Restart a columnstore policy

   SELECT alter_job(<JOB_ID>, scheduled => true);
   

   See alter_job.

6. Remove a columnstore policy

   CALL remove_columnstore_policy('crypto_ticks');
   

   See remove_columnstore_policy.

7. Disable columnstore

   If your table has s in the , you have to convert the s back to the before you disable the .

   ALTER TABLE crypto_ticks SET (timescaledb.enable_columnstore = false);
   

   See ALTER TABLE.

Reference

For integers, timestamps, and other integer-like types, data is compressed using delta encoding, delta-of-delta, simple-8b, and run-length encoding. For columns with few repeated values, XOR-based and dictionary compression is used. For all other types, dictionary compression is used.