Skippr Docs

Appearance

How Redshift Destination Authentication Works in Skippr ​

June 2026

Redshift destination authentication is multi-layered: one AWS identity calls Redshift, Redshift itself needs an IAM role for S3 staging, and the database user still needs permission to write the target schema.

Short Answer ​

Redshift destination authentication in Skippr has three moving parts. First, Skippr uses the AWS default credential chain to call the Redshift APIs. Second, Redshift itself needs iam_role_arn so it can read staged files from the configured S3 bucket during the COPY workflow. Third, the Redshift database user needs write access to the target schema.

That layered model is why the destination is powerful but easy to misread. A load into database analytics, schema public, and staging bucket my-load-bucket is only correctly authenticated when the AWS principal can reference the cluster or workgroup, Redshift can assume the S3-reading role, and the SQL-side user can create or update objects in public.

Why Teams Struggle with This ​

A single "permission denied" error can come from different identity layers here. The docs are useful because they separate them: API caller, Redshift staging role, and schema writer. If you review only one of those, you do not really know whether the destination auth model is sound.

  • The connector uses the AWS default credential chain for Redshift API access.
  • The configured iam_role_arn is a second identity boundary that lets Redshift read staged files from S3.
  • The Redshift database user also needs write access to the target schema for the load and ongoing table maintenance.
  • CDC uses staging-table MERGE, so the full auth model has to support both the initial COPY flow and later reconciliation work.

How Skippr Handles It ​

Skippr handles this complexity well by naming each boundary in the warehouse config. You can see the Redshift environment, region, staging bucket, IAM role, and schema context directly instead of guessing which credentials are doing what.

That makes a production review much more concrete. You can verify the AWS principal can reach Redshift, the staging role can read S3, and the database user can write tables. Once all three are true, the destination usually behaves predictably.

  • Authentication through the AWS default credential chain for control-plane access.
  • Explicit staging access through staging_s3_bucket, staging_s3_prefix, and iam_role_arn.
  • A documented requirement that the database user can write the target schema.
  • CDC support through staging-table MERGE with order-token and tombstone semantics.

What the First Useful Version Looks Like ​

The first useful version is one Redshift environment, one staging bucket, and one schema-writing user. That proves each identity layer under a small but realistic load.

If your team owns AWS IAM and SQL grants separately, review both at the same time. Redshift destination authentication is only simple when the layers are acknowledged instead of collapsed into one idea of "credentials."