Skippr Docs

Appearance

How Redshift Defines the Raw Data Contract ​

July 2026

For Redshift, raw data is the output of specific warehouse tables in one database, read through the Data API from a cluster or serverless workgroup.

Short Answer ​

The raw data contract for Redshift is the table shape exposed by the selected Redshift tables in the configured database. Skippr reads through the Redshift Data API, so the raw layer is the rowset those tables return from a specific cluster or serverless workgroup, namespaced as redshift.{database}.{table_name}.

That usually means the source is already somewhat curated. If you extract analytics.public.customer_ltv from Redshift, the raw contract is not a low-level application record. It is the warehouse table that Redshift already exposes. That can be the right choice, but it should be described honestly because the source boundary is farther downstream than a transactional database or event log.

Why Teams Struggle with This ​

Redshift source projects fail when teams talk about rawness in abstract terms. A Redshift table may be the right contract, but it is usually a modeled warehouse surface, not the earliest record shape in the stack.

  • The selected database and tables list define the actual source contract, not the Redshift account in general.
  • Choosing a provisioned cluster versus a serverless workgroup changes the connectivity setup, but the important data question is still which tables you are publishing.
  • The AWS principal and Redshift database user both need the right permissions before the contract can be relied on operationally.
  • If the business really needs operational history, a Redshift reporting table may already be too far downstream to qualify as the right raw source.

How Skippr Handles It ​

Skippr keeps the Redshift source honest because the connector makes you name the endpoint model, database, region, and tables. That is a helpful forcing function when the source is already a warehouse and not just an application database.

The Data API path also keeps the table boundary explicit. Teams can evaluate the exact rowset they are inheriting instead of assuming Redshift will somehow reconstruct a more primitive source history for them.

  • Reads selected Redshift tables through the Data API.
  • Supports either a provisioned cluster or a serverless workgroup.
  • Uses the namespace redshift.{database}.{table_name} for downstream raw lineage.
  • Fits warehouse-to-warehouse or warehouse-to-file handoffs where the Redshift table itself is the contract.

What the First Useful Version Looks Like ​

The first useful version is one database and one table that downstream teams already treat as trustworthy. That makes it obvious whether Redshift is a legitimate source boundary or just a convenient intermediate stop.

If you discover that the Redshift table is already too transformed, move the source boundary upstream rather than trying to call a curated warehouse table raw data.