What Access Skippr Needs to Read from Redshift

June 2026

Redshift source access is split across AWS API access and database-table access, and both halves have to be right.

Short Answer

Skippr needs an AWS principal that can use the Redshift Data API resources you reference, plus a Redshift database user that can read the selected tables. The runner also has to hit the correct regional Redshift API endpoint, which means region, cluster identifier or serverless workgroup, and database choice all have to match the environment you actually intend to read.

That two-layer model shows up quickly in production. A team may have good AWS credentials for the Data API and still get nowhere because db_user cannot read public.orders, or they may have a powerful database user but point the connector at the wrong workgroup in us-east-1 and never reach the intended warehouse at all.

Why Teams Struggle with This

Redshift source access is easy to misread because the cloud and database permissions live in different places. If you only verify one layer, the resulting failure looks confusing even though the docs are clear that both the AWS principal and the database user matter.

• The AWS principal must be authorized to use the Redshift API resources for the chosen cluster or workgroup.
• The Redshift database user still needs read access to the selected tables.
• The configured region has to match the Redshift environment the Data API call is targeting.
• Cluster mode and serverless mode use different identifiers, so a correct database name is not enough if the infrastructure reference is wrong.

How Skippr Handles It

Skippr keeps the Redshift source contract explicit by separating the infrastructure identifiers from the database user. That is useful because it matches how operators already think about Redshift: first the AWS resource, then the database inside it.

The result is a cleaner access review. You can ask whether the AWS principal can talk to the named Redshift resource and whether the database user can read the named tables, instead of treating Redshift like a single opaque login string.

• Uses the AWS default credential chain for Data API authentication.
• Supports cluster identifiers or serverless workgroup names explicitly.
• Depends on a database user with read access to the selected tables.
• Keeps Redshift source scope narrow with an optional table list.

What the First Useful Version Looks Like

The first useful version is one cluster or workgroup, one database user, one region, and one or two readable tables you can confirm through the Data API path.

If you only test the cloud side or only test the SQL side, you will miss the split-permission issue that causes most Redshift source setup churn.