Skippr Docs

Appearance

What a Good First Redshift Warehouse Setup Looks Like ​

July 2026

The smallest production Redshift destination is one COPY path from S3 into one schema, because the staging bucket and IAM role are part of the warehouse boundary.

Short Answer ​

A good first Redshift warehouse setup is one Redshift resource, one schema, one staging S3 bucket and prefix, one IAM role that Redshift can use to read staged files, and one AWS identity for the API side of the connector. The docs make that operational boundary explicit with cluster_identifier or workgroup_name, schema, region, staging_s3_bucket, staging_s3_prefix, and iam_role_arn.

That is what makes the first production boundary different from other warehouses. A successful Redshift destination is not just database access. It is also the S3 COPY path. CDC support builds on the same pattern with staging-table MERGE, _skippr_order_token, and tombstone tables, so the first staging bucket and schema should be chosen as durable parts of the load design, not as temporary placeholders.

Why Teams Struggle with This ​

Redshift setups usually feel harder than they look because there are multiple identities involved: the AWS caller, the Redshift database user, and the IAM role Redshift uses to read S3.

  • The AWS principal must be able to reference the correct Redshift API resources in the right region.
  • Redshift itself still needs iam_role_arn to read the staging bucket for COPY.
  • The database user needs write access to the target schema in addition to AWS-side permissions.
  • A staging bucket chosen casually can become long-lived infrastructure before anyone names or scopes it well.

How Skippr Handles It ​

Skippr exposes the real Redshift load shape instead of hiding it. The config shows the cluster or workgroup, the target schema, the staging bucket, and the IAM role that ties Redshift to S3.

That is a better first production setup because operators can trace the whole path: files stage to S3, Redshift reads them with the configured role, and CDC reconciliation happens through the same warehouse path.

  • Uses the AWS credential chain for the runtime side of destination auth.
  • Requires explicit staging S3 settings for the COPY workflow.
  • Depends on iam_role_arn so Redshift can read staged files.
  • Supports CDC through staging-table MERGE, order tokens, and tombstones.

What the First Useful Version Looks Like ​

The first useful version is one Redshift cluster or Serverless workgroup, one target schema, one staging S3 prefix, and one IAM role that Redshift can use to read it. That proves the real warehouse path instead of just proving a login can connect.

If the team later adds more pipelines, keep the staging path naming and IAM boundaries clean. Redshift works best when its staging design is treated as first-class production infrastructure.