Snowflake, BigQuery & Databricks · Amazon Redshift

Data skew in Redshift slices

awsMediumredshiftdata-skewslicesquery-performance

Interview question

What is data skew in Redshift, how do you detect it, and how do you fix it?

How to answer

The short answer

In an architecture like Redshift, a query runs only as fast as the slowest slice. happens when table rows are distributed unevenly across cluster slices, causing a few slices to process massive volumes while other slices finish immediately and idle.

How skew happens

Data skew is almost always caused by an improper DISTKEY. For example, if you choose country_code as your distribution key on an international sales table, but 85% of your customers live in the United States, 85% of your table rows will land on the single slice that owns the hash for 'US'. When a query scans the table, that overloaded slice runs out of memory, spills to disk, and delays the entire query.

Detecting skew

You can query system catalog views such as SVV_TABLE_INFO to inspect table distribution metrics.

SQL
SELECT 
    "table", 
    size, 
    tbl_rows, 
    skew_rows, 
    skew_sortkey1
FROM svv_table_info
WHERE "table" = 'sales_events';

A skew_rows ratio of 1.00 represents a completely balanced table. A ratio above 2.0 or 3.0 indicates serious skew that will harm query throughput. You can also inspect STV_SLICES and STV_BLOCKLIST to view the exact row count per slice.

Fixing skew

  • Switch to DISTSTYLE EVEN: If your queries rarely join on a specific column or no high-cardinality column exists, round-robin distribution guarantees perfectly balanced slices.
  • Pick a high-cardinality join key: Choose a key with millions of unique values and uniform distribution, such as user_id or order_id, rather than categorical fields like status or country.