Redshift consulting from MinervaDB covers the decisions that determine whether an Amazon Redshift warehouse is fast and affordable or slow and expensive: node family and Serverless choices, distribution and sort key design, workload management, the data lake boundary with Spectrum and Iceberg, migrations into and out of Redshift, and 24×7 Redshift support with named engineers. We are vendor-neutral. Many of our Redshift engagements end with a leaner, cheaper Redshift; some end with a migration to BigQuery, Snowflake, Databricks or ClickHouse because the workload belongs there. We will tell you which before you spend.
The State of Redshift in 2026
Amazon Redshift now offers three ways to run: provisioned clusters on RA3 nodes with managed storage, provisioned clusters on the newer Graviton-based RG nodes with an integrated data-lake query engine, and Redshift Serverless billed in Redshift Processing Units. DC2 nodes with local SSD remain available only for small compressed datasets, and DS2 dense-storage nodes are gone. Python UDFs reached end of support on 30 June 2026 and any that remain must be rewritten as SQL or Lambda UDFs.
Zero-ETL integrations from Aurora, RDS and DynamoDB, Redshift ML, data sharing across accounts and regions, and Apache Iceberg support through the data lake engine have all changed how a warehouse should be designed compared with the Redshift of five years ago. Estates built on the older assumptions are where our consulting work starts.
Node families and deprecations above follow the Amazon Redshift cluster documentation, which we re-verify at the start of every engagement.
Redshift Consulting Services
Redshift health check and cost review
A fixed-scope review of the cluster or Serverless workgroup: node type and count against measured CPU, memory and I/O, managed storage growth, table design (distribution style and key, sort keys, compression encodings, column widths), vacuum and analyze state, WLM or automatic WLM configuration, concurrency scaling usage, Spectrum scan volumes, query history from SYS_QUERY_HISTORY and the STL and SVL system tables, and the reserved-instance or Serverless spend against utilisation. The output is a prioritised findings report with the measurement behind each recommendation and the estimated effect on the monthly bill, labelled as an estimate until measured.
Table design and performance engineering
Most slow Redshift queries trace back to data distribution. A join between two large tables distributed on different keys redistributes one of them across the network on every run; a fact table with EVEN distribution and no sort key scans everything.
We redesign distribution styles (KEY, ALL, EVEN, AUTO) and sort keys (compound versus interleaved, and when to let AUTO decide) from the actual join and filter patterns in query history, fix column encodings and oversized VARCHARs, and schedule VACUUM and ANALYZE around the load windows. Query-level work uses EXPLAIN and SVL_QUERY_SUMMARY to find the broadcast joins, nested loops, spills to disk and skewed slices, and every change is verified against the same query history afterwards.
Workload management and concurrency
Dashboards timing out behind the nightly load is the classic Redshift complaint. We configure automatic WLM with query priorities and queue assignment rules, or manual WLM where the workload needs hard memory allocation, set query monitoring rules that stop runaway queries before they take the cluster down, and decide when concurrency scaling and when a Serverless workgroup for BI is the cheaper answer.
Provisioned, RA3, RG or Serverless
The right deployment depends on the shape of the load. Steady, predictable ELT with a large storage footprint usually favours RA3 or RG provisioned clusters with reserved pricing; bursty or intermittent workloads favour Serverless; mixed estates often split the two with data sharing between them. We model your query history against each option with real pricing and recommend one, including the migration path (RA3 to RG, DC2 to RA3, provisioned to Serverless) and its rollback.
Data lake, Spectrum and Iceberg
Which data belongs inside Redshift managed storage and which belongs in S3 as Parquet or Iceberg queried through Spectrum or the RG data-lake engine is a cost and performance decision we make explicitly, with partitioning and file-size guidance for the lake side. We also design the Glue Data Catalog structure and the Lake Formation permissions that go with it.
Ingestion and zero-ETL
COPY from S3 with manifest files and error handling, Kinesis Data Streams and Firehose streaming ingestion, zero-ETL integrations from Aurora MySQL, Aurora PostgreSQL, RDS and DynamoDB, change data capture through AWS DMS, and orchestration with Step Functions, Airflow or dbt. We design for idempotent loads and reconciliation, because reloads happen.
Migrations into and out of Redshift
Into Redshift from Teradata, Oracle, SQL Server, Netezza, Greenplum and on-premises PostgreSQL, using the AWS Schema Conversion Tool and DMS where they help and hand-built pipelines where they do not. Out of Redshift to BigQuery, Snowflake, Databricks or ClickHouse when the assessment says so, with SQL translation, dual-running and reconciliation, and a rehearsed cutover. We have no incentive to keep you on any engine.
Security and compliance
IAM and identity-provider federation, role-based access control with row-level and column-level security, dynamic data masking, encryption with KMS keys, audit logging to S3 and CloudTrail, VPC and enhanced VPC routing, and the evidence for SOC 2, HIPAA, PCI DSS and GDPR reviews.
What the Redshift Health Check Measures
Every recommendation in a MinervaDB Redshift health check names the system table or metric that justifies it. The core evidence set:
| Area | Evidence | Typical finding |
|---|---|---|
| Table design | SVV_TABLE_INFO (skew, unsorted %, encoding, size), PG_TABLE_DEF |
Fact tables with high skew or unsorted regions above 20%; raw encodings on wide columns |
| Query performance | SYS_QUERY_HISTORY, SVL_QUERY_SUMMARY, SVL_QUERY_REPORT, STL_ALERT_EVENT_LOG |
Broadcast and redistribution steps on large joins; nested loops; spills to disk |
| Workload management | STL_WLM_QUERY, SVL_QUERY_QUEUE_INFO, STV_WLM_SERVICE_CLASS_STATE |
BI queries queued behind ELT; memory allocated to queues that never fill |
| Maintenance | SVL_VACUUM_PERCENTAGE, STL_VACUUM, STL_ANALYZE |
Auto vacuum not keeping up with delete-heavy loads; stale statistics on staging tables |
| Capacity and cost | CloudWatch CPU, disk, queue metrics; Cost Explorer; concurrency scaling and Spectrum usage | Clusters at 25% CPU outside the load window; concurrency scaling credits burned on badly written dashboards |
| Data lake boundary | SVL_S3QUERY_SUMMARY, Spectrum scan bytes |
Hot data in S3 scanned daily that should be a managed table, and cold managed tables that should be Parquet in S3 |
| Security | User and role catalogs, audit log configuration, parameter groups | Shared superuser accounts; audit logging disabled; SSL not enforced |
How a Redshift Engagement Runs
Week one: evidence
Read-only access through a cross-account role and a database user with catalog visibility. We collect the system-table evidence above, 90 days of query history and the billing data, and deliver the findings report ranked by cost and latency impact, each item with its measurement and its estimated effect.
Weeks two to four: changes with rollback
Table redesigns are done by creating the new table, loading with INSERT ... SELECT or a deep copy, validating counts, and swapping names inside a transaction so the change reverses in seconds. WLM changes are staged with a monitoring window. Node or Serverless migrations are rehearsed on a restored snapshot first. Every change is recorded with its before-and-after evidence.
Ongoing: measurement and support
The same query-history analysis runs monthly under the support retainer, so regressions are caught when a new dashboard or pipeline lands, not when the bill arrives.
Redshift and the Rest of the Estate
Redshift is rarely alone. The source systems are usually RDS or Aurora PostgreSQL and MySQL, the lake is S3 with Glue, the streaming path is Kinesis or Kafka, and there is often a second warehouse or a ClickHouse cluster serving the customer-facing analytics. Our AWS data platform engineering team covers all of these, our Kafka consulting practice owns the streaming layer, and the data engineering team builds the pipelines between them. That matters for Redshift specifically because half of Redshift performance problems originate upstream: unsorted loads, missing partition pruning in Spectrum, or CDC pipelines that generate delete-heavy churn the vacuum cannot absorb.
24×7 Redshift Support
The support retainer gives you named engineers on a 24×7 rota for failed loads, hung queries, disk-full and WLM queue incidents, cost spikes and version or maintenance-window problems, plus proactive monthly reviews of query history, storage growth and spend. Severity targets: S1 acknowledged within 15 minutes around the clock, S2 within 12 hours, S3 within 24 hours, S4 within 48 hours. Every S1 closes with a written root-cause analysis. Redshift support sits within our AWS data platform engineering practice, so RDS, Aurora, DynamoDB and Glue work is covered by the same team, and within data analytics and data warehousing support for organisations running more than one warehouse.
Pricing
Remote consulting is US $300 per hour, on-site consulting US $500 per hour plus travel, and 24×7 support retainers start at US $4,500 per quarter with unused hours rolling into project work within the quarter. Health checks and migrations are quoted on a fixed scope. Test every change in a non-production cluster or a restored snapshot first, keep manual snapshots before table redesigns and version changes, and maintain a robust disaster-recovery posture with cross-region snapshot copies.
Frequently Asked Questions
Can you cut our Redshift bill?
We usually find savings in oversized clusters, idle concurrency scaling, Spectrum scans that should be managed tables (or the reverse), and reserved-instance mismatches. Every saving we quote is modelled from your own query history and billing data and labelled as an estimate until it shows up on the invoice.
Should we move to Redshift Serverless?
It depends on the load shape. Intermittent and bursty workloads often cost less on Serverless; steady, heavy ELT usually costs less on reserved RA3 or RG nodes. We model both against your history before recommending.
Do you help with the Python UDF end of support?
Yes. Python UDFs reached end of support on 30 June 2026. We inventory any that remain from the system catalog, rewrite them as SQL UDFs or Lambda UDFs, and regression-test the results as an S2 priority.
Can you migrate us off Redshift?
Yes, to BigQuery, Snowflake, Databricks or ClickHouse, and we will say plainly if we think you should stay.
Do you cover Aurora and RDS as well as Redshift?
Yes. Zero-ETL integrations, RDS and Aurora tuning, and the operational side of the source systems are all handled by the same AWS practice; see our Amazon RDS support page.
How do we start?
Book a scoping call. Most engagements begin with the health check and cost review.