Skippr Docs

Appearance

Common Redshift Source Setup Mistakes ​

May 2026

Redshift source setup often breaks when teams think in JDBC terms while the connector is actually using the Redshift Data API.

Short Answer ​

The most common Redshift source mistakes are supplying the wrong cluster or workgroup identity, mixing up the Redshift database user with AWS credentials, and forgetting that the source connector reads through the Redshift Data API. Skippr expects a database name plus either a cluster_identifier or a workgroup_name, along with region and optional db_user values depending on the Redshift deployment mode.

That distinction matters because a team can have perfectly good AWS credentials and still point the source at the wrong Redshift resource. Another common issue is granting AWS access to call the Data API while forgetting that the Redshift database user also needs read access to the selected tables, which creates a split-permission failure that looks mysterious if you only inspect the cloud side.

Why Teams Struggle with This ​

Redshift source setup has a two-layer access model: the AWS principal needs permission to use the Redshift Data API resources, and the Redshift database user needs permission to read the tables themselves. Teams often validate one layer and assume the other comes along for free.

  • Using cluster_identifier when the environment is actually Serverless, or vice versa, points Skippr at the wrong resource model.
  • The AWS credential chain and the Redshift db_user solve different problems and both may matter.
  • Region mismatches can make otherwise valid Redshift resources appear missing or unauthorized.
  • A readable cluster is not a readable schema unless the Redshift-side user can access the selected tables.

How Skippr Handles It ​

Skippr keeps the Redshift source configuration concrete by exposing the exact resource selectors the Data API expects: cluster or workgroup, database, database user, tables, and region. That is more helpful than pretending Redshift is just another direct SQL socket.

Because the connector surface is explicit, setup reviews can ask the right question: does the AWS principal have Data API access, and does the Redshift-side user have table read access? Those are the two gates the pipeline actually has to pass.

  • Redshift source configuration aligned with the Data API model rather than direct driver assumptions.
  • Support for both provisioned clusters and Serverless workgroups.
  • Explicit database, db_user, tables, and region fields for controlled source scope.
  • A source contract that distinguishes AWS access from warehouse table permissions.

What the First Useful Version Looks Like ​

A good first version is one clearly identified Redshift cluster or workgroup, one database, and one table list small enough to validate quickly.

Before broadening the extract, confirm that both the AWS principal and the Redshift-side user have the access they need, because either side can stop the source cold.