Skippr Docs

Appearance

How to Configure Redshift as a Warehouse Destination ​

May 2026

Redshift destination setup works best when the staging bucket and IAM role are treated as part of the warehouse contract, not an afterthought.

Short Answer ​

Configure Redshift as a warehouse destination by setting warehouse.kind to redshift, then providing database, schema, region, and either cluster_identifier or workgroup_name. You also need the staging controls the docs call out: staging_s3_bucket, staging_s3_prefix, and iam_role_arn, because Skippr uses an S3-backed COPY workflow before Redshift reconciles data into the target tables.

A clean first setup often looks like one dedicated staging bucket prefix such as skippr/staging/, one IAM role Redshift can assume to read those files, and one database user with write access to the destination schema. That gives you a predictable first write: Skippr stages the files in S3, Redshift COPY reads them, and the warehouse tables land in the schema you planned for raw data.

Why Teams Struggle with This ​

Redshift destination issues almost always cross service boundaries. A warehouse block can look correct while the IAM role cannot read the bucket, the bucket is in the wrong region, or the Redshift user can authenticate but not write into the target schema.

  • The destination must identify either a provisioned cluster or a Serverless workgroup.
  • The staging S3 bucket and prefix are required operational pieces because Redshift loads through COPY.
  • iam_role_arn must let Redshift read from the staging bucket.
  • The database user still needs write access to the chosen schema even when the AWS pieces are correct.

How Skippr Handles It ​

Skippr reflects the real Redshift loading model instead of abstracting it away. You declare the warehouse target, the staging bucket details, and the IAM role Redshift uses, which means the first successful configuration is already aligned with how production COPY workflows behave.

That pays off immediately during validation. You can inspect the S3 staging location, confirm Redshift can assume the intended role, and verify that tables are landing in the right schema before layering on more sources or CDC final-state reconciliation.

  • Warehouse config that includes both Redshift target settings and required S3 staging controls.
  • Authentication via the AWS default credential chain for API access.
  • An explicit iam_role_arn so Redshift can read staged files during COPY.
  • A destination model that scales naturally into Redshift CDC final-state tables.

What the First Useful Version Looks Like ​

Treat the staging prefix as an owned operational area and not a generic shared bucket path, because copy failures are easier to debug when staging is isolated.

Before rollout, validate the IAM relationship from Redshift to S3 and the schema-level write privileges together, since both are required for a clean first load.