Redshift Consulting: Proven Tuning, Migration & 24×7 Support

Three deployment forms exist today. Provisioned clusters on RA3 nodes keep hot blocks on local SSD and hold the full dataset in Redshift Managed Storage on S3, up to 128 TB per node on ra3.4xlarge and ra3.16xlarge. Provisioned clusters on RG nodes, generally available since May 2026, run on AWS Graviton with an integrated data lake query engine that reads Iceberg and Parquet directly, so the Spectrum fleet and its US $5 per terabyte charge disappear.

AWS quotes 30% lower cost per vCPU than RA3 and up to 2.4× faster Iceberg queries at 10 TB scale. Redshift Serverless bills in Redshift Processing Units from a base of 4 to 1,024 RPU, and since April 2026 new workgroups default to AI-driven scaling that adds capacity before queries queue rather than after.

DC2 nodes with local NVMe remain the right answer only for datasets under about 1 TB compressed. DS2 dense-storage nodes are no longer available. Python UDFs reached end of support on 30 June 2026 and patch 203 began enforcing it, so any estate still carrying them has reports that are already broken or about to be.

The release cadence matters for operations. Redshift ships numbered patches to a current and a trailing maintenance track; patch 205 (cluster version 1.0.434008, 16 September 2026) added Iceberg materialized views with incremental refresh, automatic bloat removal with superblock shrinking, post-quantum hybrid TLS key exchange and gzip and bzip2 reads for Spectrum. Patch 204 brought Iceberg v3 tables with deletion vectors, a persistent query_uuid in the system tables, account lockout after repeated failed sign-ins and single-node rg.large clusters.

Patch 203 made tables with a primary key eligible for automatic DISTKEY assignment. Each of those changes a tuning decision we would have made differently a year ago.

That is the frame for every Redshift consulting engagement we take: AWS owns the platform, the warehouse design is yours, and a bigger node is not a substitute for either. Node families and dates above follow the Amazon Redshift cluster documentation and the cluster version history, which we re-verify at the start of every engagement.

Distribution decides join cost

Rows live on slices. A join between two tables distributed on the join column completes on each slice with no network step; the plan shows DS_DIST_NONE. If the inner table is small the planner broadcasts it to every slice (DS_BCAST_INNER), which is cheap until statistics go stale and the "small" table is 400 million rows. If neither table is on the join key the planner re-hashes both across the network (DS_DIST_BOTH), and that is the shape of almost every "this query takes eleven minutes" ticket we receive.

The fix is usually a DISTKEY on the join column for the largest fact tables and DISTSTYLE ALL for dimensions under a few million rows, with AUTO left in charge of the long tail. Since patch 203 Redshift will assign a DISTKEY automatically to tables with a primary key; we verify that it chose the column your queries actually join on, because a primary key and a join key are not always the same thing. Skew is checked in SVV_TABLE_INFO.skew_rows before and after.

Sort keys decide scan cost

A compound sort key on the columns dashboards filter by lets zone maps skip most blocks. Interleaved keys were the answer for many equally-likely filter columns and are now largely superseded by the multidimensional data layout sort key introduced in patch 202, which is worth testing on wide fact tables with unpredictable predicates. SVV_TABLE_INFO.unsorted above 20% on a table that is queried daily means vacuum is not keeping up with the load pattern and the load pattern, not the vacuum schedule, is what we change.

Reading the plan the way the engine does

Every Redshift consulting report we write starts from this pair of queries, run against the last seven days before anyone touches a parameter.

-- Five worst queries by execution time, last 7 days.
-- Queue time kept separate: a WLM problem is not a SQL problem.
SELECT query_id,
       user_id,
       ROUND(elapsed_time / 1e6, 1)   AS elapsed_s,
       ROUND(queue_time / 1e6, 1)     AS queue_s,
       ROUND(execution_time / 1e6, 1) AS exec_s,
       returned_rows,
       LEFT(query_text, 80)           AS query_text
FROM   sys_query_history
WHERE  start_time > DATEADD(day, -7, GETDATE())
AND    status = 'success'
ORDER  BY execution_time DESC
LIMIT  5;

-- Step-level detail for one query: which step redistributed or spilled
SELECT step_id, step_name,
       SUM(input_rows)   AS input_rows,
       SUM(output_rows)  AS output_rows,
       SUM(spilled_block_local_disk + spilled_block_remote_disk) AS spilled_blocks,
       MAX(duration) / 1e6 AS max_slice_s
FROM   sys_query_detail
WHERE  query_id = ${QUERY_ID}
GROUP  BY step_id, step_name
ORDER  BY step_id;

Two things fall out of that pair almost every time. A step whose slowest slice takes five times the median is skew, not volume. A join step with spilled blocks on a cluster that "has plenty of memory" is a WLM slot with too little memory for the queue it sits in. Neither is fixed by adding nodes.

Moving from RA3 to RG

For most clusters the move is an elastic resize that keeps the endpoint and takes roughly 10 to 15 minutes, during which the cluster is read-only, zero-ETL tables go into resync and data shares pause for a few minutes. Classic resize handles node configurations elastic resize cannot and rebalances slices evenly, at the cost of a longer window and a fresh manual snapshot no older than ten hours.

Snapshot-and-restore builds an RG twin beside the RA3 cluster for validation with no production downtime, at the cost of a new endpoint and re-created zero-ETL integrations. We rehearse the chosen path on a restored snapshot, measure the top fifty queries on both, and only then book the window. Reverting to RA3 works by the same mechanisms, which is what makes the change acceptable to a Redshift consulting practice that treats every cluster as production.

How the cost model is built

We take 90 days of SYS_QUERY_HISTORY, bucket execution seconds and scanned bytes by hour, and replay the profile against on-demand and reserved RA3 and RG pricing and against Serverless RPU-hours at the observed concurrency. Spectrum scan bytes from SVL_S3QUERY_SUMMARY and SYS_EXTERNAL_QUERY_DETAIL are priced separately for RA3 and zeroed for RG. Managed storage is priced from SVV_TABLE_INFO.size growth, and concurrency scaling seconds from SVCS_CONCURRENCY_SCALING_USAGE. The output is three monthly numbers per candidate with the assumptions written next to them. AWS's own migration guidance is at RA3 to RG migration best practices; our Redshift consulting model is what tells you whether it applies to you.