Skippr Docs

Appearance

When to Use Redshift as a Source Connector ​

June 2026

The Redshift source connector is right when Redshift already contains the modeled tables you want to move and the Data API is the simplest extraction boundary.

Short Answer ​

Use the Redshift source connector when the useful dataset already exists in Redshift and the cleanest path is to read those tables through the Redshift Data API. It is a good fit when Redshift has become the effective source of record for curated analytical tables and the downstream system should receive those tables directly rather than recomputing them elsewhere.

A typical example is a team with one Redshift cluster that already houses reporting-grade customer or revenue tables, but another destination now needs the same outputs. Skippr can connect through the cluster identifier or serverless workgroup, database, region, and optional database user, then extract a small set of tables without bolting on another export job.

Why Teams Struggle with This ​

Redshift as a source is useful when the warehouse is already part of the business contract, but it is a bad fit if the team actually needs lower-level operational data or expects a simple direct socket connection. The connector is intentionally Data API based.

  • The AWS principal needs permission to use the referenced Redshift Data API resources.
  • The Redshift database user still needs read access to the selected tables.
  • You have to choose between a provisioned cluster identifier and a serverless workgroup, which is an early configuration fork.
  • If the real need is faster or more granular upstream data, Redshift is often too far downstream to serve as the right source.

How Skippr Handles It ​

Skippr keeps the extraction contract clear: one Redshift endpoint model, one database, one region, and a list of tables. That makes the connector a good fit for warehouse-to-warehouse or warehouse-to-file handoffs where the analytical model already exists.

Because the connector uses the AWS default credential chain, it also fits teams that already run infrastructure with standard AWS auth rather than maintaining a separate database secret flow.

  • Reads from Amazon Redshift through the Data API.
  • Supports provisioned clusters or serverless workgroups.
  • Uses the AWS default credential chain for authentication.
  • Works best for extracting selected curated tables from an existing Redshift environment.

What the First Useful Version Looks Like ​

The first useful version is one cluster or workgroup, one database, and a short table list that proves the Data API path and permissions are stable.

Redshift is a bad fit when the useful data contract actually lives upstream, or when the Data API and database permissions are harder to secure than a direct integration from the original source.