Storage Optimization

​

Table-Level Storage Optimizations

• Apply column compression — Choose a compression scheme for each column based on its data type and cardinality to reduce on-disk size. The system supports ZSTD compression for strong general-purpose compression, Global Dictionary Compression (GDC) for low-cardinality variable-length columns, and dynamic compression (the default) for automatic lightweight encoding with no configuration required. You can stack GDC and ZSTD for additional savings. For details, see Table Compression Options and Global Dictionary Compression.
• Use appropriate data types — Select the narrowest data type that fits your data. For example, use SMALLINT or INT types instead of BIGINT when the value range allows. For columns with low cardinality, consider GDC to convert variable-length values to fixed-width integers.
• Leverage complex types to avoid extra tables — Use arrays, tuples, and arrays of tuples to denormalize one-to-many relationships into a single column instead of creating separate child tables. This denormalization eliminates the storage overhead of duplicated foreign keys and additional indexes. For details, see Array, Tuple, and Matrix Overview.
• Index selectively — Secondary indexes improve query performance but consume additional storage. Create indexes only on columns that appear frequently in query predicates. Avoid redundant indexes on columns that are already covered by the clustering key or a clustering index. For details about the different index types available and when to use each one, see Secondary Indexes.
• Configure the redundancy mode — When creating a table, you can choose between COPY and PARITY redundancy for each segment part. PARITY redundancy uses erasure coding, which consumes less storage than full replication (COPY) but incurs additional CPU overhead during rebuilds or degraded-state queries. For details, see the REDUNDANCY parameter in Tables.

​

System-Level Storage Configuration

​

Data Lifecycle and Ongoing Storage Management

• Table retention policies — Automatically remove aged data by configuring the RETENTION POLICY on tables with a column. The system periodically evaluates each row against the retention period and deletes rows that exceed it. This approach is ideal for time series and streaming workloads where historical data has diminishing value. For details, see Table Retention Policies.
• TRUNCATE TABLE SQL statement for space reclamation — When removing large volumes of data, use the TRUNCATE TABLE SQL statement instead of the DELETE statement. Both operations reclaim disk space, but the DELETE statement can reclaim storage only for segment groups in which all rows have been removed. The TRUNCATE TABLE statement removes all rows from the table and reclaims all associated storage. For details, see Remove Records from an Ocient System.
• Removal of unused indexes — Periodically audit secondary indexes using the system catalog. Dropping an index prevents it from being created in future segments, reducing storage growth over time. Use the DROP INDEX SQL statement to remove unneeded indexes. For details, see Secondary Indexes.
• Monitoring of storage utilization — Use the sys.storage_used system catalog table to inspect per-node, per-table storage consumption. Identifying the largest tables and their compression ratios reveals opportunities for further optimization. For details, see System Catalog.

​

Related Links