Redshift.

Where Redshift fits on a long engagement.

Redshift performance is a function of physical design far more than of query text. Distribution style decides whether a join happens locally or redistributes data across the network, and a table distributed on the wrong column turns a fast join into a cluster-wide data movement. That decision is the main lever and the one most often made by default.

Concurrency is the other recurring problem. A small number of heavy queries can occupy the cluster and leave dashboards timing out, and without workload management to separate the two, one analyst's exploratory query becomes everyone's outage.

What an assigned team does with Redshift.

Warehouses degrade quietly. Tables grow, statistics go stale, vacuum is not run, and queries that were fast last year now take minutes with nothing in the change log to explain it.

Routine maintenance and a periodic review of the physical design is ongoing work rather than a migration task, and it is the kind of standing responsibility described in how an assignment runs.

What we use Redshift for.

• Distribution designed for the joins Keys chosen so the common joins stay local rather than redistributing across nodes.
• Dashboards protected from ad-hoc queries Workload management separating interactive from exploratory, so one does not starve the other.
• Maintenance that keeps performance stable Vacuum and statistics on a schedule, so degradation is prevented rather than investigated.

How Redshift capacity is assigned.

Warehouse capacity is assigned under managed data services, with physical design reviewed periodically rather than fixed at load.