Skippr Docs

Appearance

What Network or Staging Access Redshift Needs ​

July 2026

Redshift destination access is a two-part path: the runner reaches Redshift and the staging bucket configuration lets Redshift read the files it must COPY.

Short Answer ​

Redshift needs two distinct access paths: the runner needs access to the Redshift API resources in the configured region, and Redshift itself needs access to the staging S3 bucket through the configured iam_role_arn. The destination docs make that structure explicit with staging_s3_bucket, staging_s3_prefix, region, and iam_role_arn, so the load boundary is not just the warehouse. It is warehouse plus staging bucket working together through the COPY workflow.

That staging shape is the first thing to understand before anything else. If the target is cluster my-cluster in us-east-1 and the staging path is s3://my-load-bucket/skippr/staging/, the runner needs AWS rights to use the Redshift resources it references, while Redshift needs the attached IAM role to read from that exact S3 location. If either side is wrong, the load path is broken even if the database user and schema name are correct.

Why Teams Struggle with This ​

Redshift warehouse setups often get stuck because people think about only one side of the path. They check Redshift credentials or schema grants, but the actual blocker is a staging bucket prefix or IAM role that Redshift cannot use for COPY.

  • The runner needs the right AWS access to the Redshift cluster or serverless workgroup in the configured region.
  • Redshift must be able to read the staging S3 bucket and prefix through iam_role_arn.
  • The database user still needs write access to the target schema after the staged files arrive.
  • CDC uses staging-table plus MERGE semantics, so the same warehouse path has to support both file loading and final-state reconciliation.

How Skippr Handles It ​

Skippr is useful here because it exposes the actual Redshift load shape instead of hiding it. You configure the warehouse endpoint details and the staging S3 details together, which makes it much easier to see where the break is when a COPY fails.

That same clarity helps with CDC. Once the staging bucket and IAM role are correct, Skippr can use Redshift staging-table and MERGE with _skippr_order_token and tombstones, so the warehouse stays grounded in one consistent load model.

  • Uses a documented S3 staging bucket and prefix for the COPY workflow.
  • Requires an IAM role that lets Redshift read the staged files.
  • Targets either a Redshift cluster or serverless workgroup in one region.
  • Applies CDC through staging-table MERGE with automatic order-token and tombstone support.

What the First Useful Version Looks Like ​

The first useful version is one Redshift deployment, one staging bucket prefix, one IAM role, and one small table load that proves the full COPY chain works.

If the staging bucket still feels ambiguous, keep the footprint tiny. Redshift becomes much easier once the COPY path is fully visible and repeatable.