Skippr Docs

Appearance

How Redshift Shapes the Warehouse Contract ​

July 2026

Redshift is a good warehouse contract when the team is willing to treat the staging bucket and IAM role as part of how tables become trustworthy current-state interfaces.

Short Answer ​

Redshift shapes the warehouse contract around the destination schema and the staging path that feeds it: staging_s3_bucket, staging_s3_prefix, and iam_role_arn. The destination docs describe a COPY workflow, and the CDC docs add the second half of the contract: staged data is merged into the target table with newer-wins logic based on _skippr_order_token VARCHAR(MAX), while tombstone tables preserve delete order.

That means the final table is the analytical contract, but the staging S3 path is still a first-class operational dependency. If data lands in analytics.public.orders, analysts should query that Redshift table. At the same time, the team needs to understand that the table only becomes correct because Redshift can read the staged files and then run the guarded MERGE step that resolves business keys and deletes.

Why Teams Struggle with This ​

Redshift contracts become brittle when teams only explain the table and skip the staging chain behind it. COPY success alone does not define current state, and MERGE correctness alone is irrelevant if the staging bucket or IAM role is wrong.

  • The staging S3 bucket and prefix are operational parts of the warehouse contract, not disposable side details.
  • A valid Redshift schema still is not usable if iam_role_arn cannot read the staged files Redshift needs for COPY.
  • Treating the post-COPY table as append-only hides the actual CDC contract, which is newer-wins merge by business key.
  • Cluster or workgroup choice matters because it defines which Redshift environment owns the tables downstream users will trust.

How Skippr Handles It ​

Skippr makes Redshift explicit by exposing both the landing schema and the S3 staging controls in config. That is helpful because it keeps the whole load chain reviewable rather than reducing Redshift to a database name and a hope that COPY will sort itself out.

The CDC behavior stays equally visible. Skippr stages efficiently, then applies changes with MERGE, order-token guards, and tombstones so the final Redshift table becomes the current-state interface the rest of the stack can depend on.

  • Targets an explicit Redshift database and schema.
  • Uses S3 staging plus COPY before CDC reconciliation.
  • Requires an IAM role Redshift can use to read the staging bucket.
  • Applies final-state logic with MERGE, _skippr_order_token, and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one Redshift schema, one staging S3 prefix, and one CDC-managed table that you can trace from staged file to final row state. That teaches the full contract in one concrete path.

If the team still treats staging as an afterthought, keep the first release small until the COPY chain and the final-state table behavior can be explained together. Redshift is easiest to support when both stages are part of the design, not a surprise.