Skippr Docs

Appearance

How to Define Redshift Ingestion Scope Clearly ​

July 2026

A clean Redshift source boundary starts with the exact cluster or workgroup and database, then narrows to the tables the Data API reader should expose.

Short Answer ​

Define Redshift ingestion scope with one cluster_identifier or one workgroup_name, one database, one db_user, and, when you want a narrow handoff, an explicit tables list. The source docs describe Redshift as a Data API reader, so the source boundary is not generic AWS access. It is a specific Redshift environment and the objects that user can read there.

That means a config such as cluster_identifier: analytics-prod, database: warehouse, db_user: skippr_reader, and tables: public.orders,public.customers is a concrete contract. If you choose not to list tables, review the Redshift user privileges carefully because they become the practical limit on what the connector can query through the Data API.

Why Teams Struggle with This ​

Redshift scope becomes blurry when teams stop at AWS authentication and never define the database objects that should count as the handoff. Data API access and table-level scope are different layers, and both need to be named.

  • A valid AWS principal still does not tell you which Redshift database and tables the connector should expose.
  • Confusing provisioned clusters and Serverless workgroups makes the source boundary harder to describe and troubleshoot.
  • Leaving the table decision implicit often turns the Redshift user grants into the real boundary without anyone reviewing them as such.
  • A Data API connection that works in the wrong region or wrong database is still the wrong source.

How Skippr Handles It ​

Skippr makes Redshift scope reviewable because the connector names the real boundaries directly: cluster or workgroup, database, optional database user, optional tables, and region. That is enough to tell whether the source is a specific curated slice or a broader warehouse surface.

This works best when Redshift already contains stable tables the team is comfortable treating as source interfaces. If the warehouse objects are still highly temporary, the article should say so plainly rather than overstate the boundary quality.

  • Reads Redshift over the AWS Redshift Data API rather than a generic SQL socket.
  • Supports either a provisioned cluster or a Serverless workgroup as the source environment.
  • Lets teams narrow scope with an explicit table list when they want a cleaner boundary.
  • Separates AWS API access from the Redshift database user that actually reads the tables.

What the First Useful Version Looks Like ​

The first useful version is one Redshift cluster or workgroup, one database, and one or two tables that already act like durable interfaces. That proves both Data API access and the table boundary together.

If the source still depends on "whatever this warehouse user can read," tighten the grants or add a table list before downstream consumers start treating Redshift as a stable published source.