Skippr Docs

Appearance

How to Configure Redshift as a Source Connector ​

May 2026

Redshift source setup is mostly about identifying the right cluster or workgroup and making sure the AWS principal can use the Data API.

Short Answer ​

Configure Redshift as a source by setting source.kind to redshift_source, then choosing either cluster_identifier for provisioned clusters or workgroup_name for Serverless. Add database, region, optional db_user, and the initial tables list so Skippr knows exactly which Redshift objects to query through the Data API.

A clean first setup usually names one cluster or workgroup, one database, and a short list such as public.customers,public.orders. Because authentication uses the AWS default credential chain, the important setup step is making sure the AWS identity can call the Redshift Data API while the database user itself can read the tables you selected.

Why Teams Struggle with This ​

Redshift source issues often combine cloud and database permissions. The AWS caller may have access to one cluster but not the region you configured, or the Data API call may succeed while the database user lacks read access to the target tables.

  • You need to choose either cluster_identifier or workgroup_name to match the Redshift deployment model.
  • The AWS principal must be able to use the Redshift Data API resources in the configured region.
  • The database user needs read access to the selected tables.
  • The runner must reach the regional Redshift API endpoint even though the connector is not using a direct SQL client session.

How Skippr Handles It ​

Skippr keeps the Redshift source close to how the platform is administered: AWS identity for API access, database context for table reads, and a clear choice between provisioned and Serverless targets. That makes it easier to line the connector up with whatever operational model your Redshift team already supports.

The first healthy setup should be easy to explain. Skippr can authenticate through AWS, address the correct cluster or workgroup, query the selected database tables, and preserve a namespace that clearly reflects which Redshift objects were extracted.

  • Redshift Data API source support for both provisioned clusters and Serverless workgroups.
  • Authentication via the AWS default credential chain.
  • Explicit database, db_user, region, and tables controls.
  • A clean first-read pattern that works well for narrow warehouse extracts.

What the First Useful Version Looks Like ​

Start with a short table list and confirm the same AWS principal you plan to run in production can execute the Data API calls successfully.

If the source spans multiple Redshift environments, treat each cluster or workgroup as its own connector so database context and permissions stay unambiguous.