Skippr Docs

Appearance

When Redshift Is the Right System Boundary ​

July 2026

Redshift is the right system boundary when the useful dataset already exists in Redshift and moving those curated tables is more sensible than reaching back to the original operational systems.

Short Answer ​

Redshift is the right system boundary when the curated analytical tables already live there and the Redshift Data API is the simplest extraction surface. The source docs are clear about that contract: you choose a cluster_identifier or workgroup_name, a database, optional db_user, region, and a list of tables to read.

That is a good fit for warehouse-to-warehouse or warehouse-to-file handoffs where the modeled data already exists in Redshift. If finance, operations, or product reporting already depends on Redshift tables that have settled names and definitions, extracting those tables directly can be more honest than pretending the real boundary still lives in the originating application database.

Why Teams Struggle with This ​

Redshift is a poor source boundary when it is only a convenient place to reach from AWS and not the actual home of the contract. If downstream teams still argue about whether the warehouse tables are authoritative, moving the boundary into Redshift usually bakes in that uncertainty rather than fixing it.

  • The AWS principal must be allowed to use the referenced Redshift Data API resources.
  • The Redshift database user still needs read access to the selected tables.
  • You must choose between a provisioned cluster and a serverless workgroup, which affects how the connector is configured.
  • If the real need is lower-level operational data or finer-grained history, Redshift is often too far downstream.

How Skippr Handles It ​

Skippr works well here because the connector speaks Redshift in Redshift terms: cluster or workgroup, database, region, and tables. That keeps the handoff grounded in the warehouse boundary the organization already understands.

Because authentication uses the AWS default credential chain, this source also fits teams that already manage infrastructure through standard AWS identity instead of a separate warehouse password distribution process.

  • Reads from Amazon Redshift through the documented Data API.
  • Supports either provisioned clusters or serverless workgroups.
  • Uses the AWS default credential chain for authentication.
  • Works best for selected curated tables that are already meaningful in Redshift.

What the First Useful Version Looks Like ​

The first useful version is one cluster or workgroup, one database, and a short list of tables whose meaning is already agreed across teams.

If the tables are still being treated as provisional or disposable, Redshift is probably a convenient stop rather than the real system boundary.