Skippr Docs

Appearance

What Access Skippr Needs to Write to Redshift ​

June 2026

Redshift write access spans AWS, S3 staging, and database privileges, so a single credential check is never enough.

Short Answer ​

Skippr needs an AWS principal that can use the referenced Redshift resources, a staging S3 bucket and prefix, an iam_role_arn that lets Redshift read from that bucket, and a Redshift database user with write access to the target schema. The destination docs are explicit because the write path is explicit: Skippr stages files in S3 and Redshift loads them through COPY before CDC MERGE logic takes over.

A concrete setup might use staging_s3_bucket: my-load-bucket, staging_s3_prefix: skippr/staging/, and a role like arn:aws:iam::123456789012:role/RedshiftS3Role. Even if the Redshift user can write into schema raw, the destination is still blocked if Redshift itself cannot read the staged files from S3.

Why Teams Struggle with This ​

Redshift fails in a very specific way when teams only validate one access layer. The AWS identity may be fine but the database user lacks schema privileges, or the database user may be powerful while the staging bucket and IAM role are still not usable by Redshift.

  • The AWS principal has to reach the intended Redshift cluster or serverless workgroup and related API resources.
  • Redshift must be able to read the staging S3 bucket through the configured iam_role_arn.
  • The database user needs write access to the target schema.
  • CDC uses staging-table MERGE semantics, so both the COPY path and the schema-write path must work for final-state tables to stay healthy.

How Skippr Handles It ​

Skippr makes the Redshift write model easier to reason about because it names every real moving part: cluster or workgroup, database, schema, region, staging bucket, staging prefix, and IAM role. That keeps setup reviews tied to the actual COPY workflow Redshift uses rather than to vague warehouse language.

The CDC destination docs then make the reconciliation layer explicit. Redshift uses a staging table plus MERGE with order-token guards and tombstones, which means the destination permissions are not just about loading files. They are about maintaining current-state warehouse tables after the load.

  • Uses the AWS default credential chain for the Redshift control path.
  • Stages load files in S3 before COPY into Redshift.
  • Requires an IAM role that lets Redshift read from the staging bucket.
  • Uses MERGE plus order-token and tombstone protections for CDC-managed tables.

What the First Useful Version Looks Like ​

The first useful version is one cluster or workgroup, one database, one writable schema, and one staging bucket whose policy and IAM role you can test end to end.

If COPY and MERGE are both clean on a single small table, you have proved the real Redshift access chain rather than just one piece of it.