Skippr Docs

Appearance

When to Use Redshift as a Warehouse Destination ​

June 2026

Redshift is the right destination when the team wants a familiar SQL warehouse and is willing to own the S3 staging and IAM pieces that make the load path work.

Short Answer ​

Use Redshift as a warehouse destination when you want a familiar SQL warehouse with predictable COPY-based loading, S3-backed staging, and final-state CDC tables that reconcile through a staging-table MERGE pattern. It is a strong fit when the team is comfortable treating the staging bucket, prefix, IAM role, and cluster or workgroup settings as first-class parts of the warehouse contract.

A good example is a team loading operational tables into Redshift for current-state analytics. Skippr can stage files in S3, let Redshift COPY them in, and reconcile CDC-managed tables with staging-table MERGE semantics, order tokens, and tombstones so deletes and retries behave predictably.

Why Teams Struggle with This ​

Redshift is a very practical warehouse only when the staging path is treated as part of the design, not as a hidden implementation detail. The destination requires more setup than a direct database write, and that tradeoff should be chosen on purpose.

  • You need a staging S3 bucket and prefix before COPY-based loads can work.
  • Redshift must be able to assume the configured IAM role to read those staged files.
  • The target database user still needs write access to the chosen schema.
  • If the team wants the lightest possible warehouse setup with no staging infrastructure, Redshift is usually the wrong choice.

How Skippr Handles It ​

Skippr makes Redshift workable by exposing the actual staging controls instead of burying them. The warehouse config includes database, region, cluster or workgroup settings, staging bucket and prefix, and the IAM role Redshift uses to read from S3.

That clarity helps because Redshift is excellent once the boundary is explicit. The same setup that handles COPY loading also supports exactly-once final-state CDC reconciliation with automatic _skippr_order_token columns and tombstone tables.

  • Loads through the documented S3 staging plus COPY workflow.
  • Supports either a provisioned cluster or Redshift Serverless workgroup.
  • Uses staging-table MERGE semantics for final-state CDC.
  • Automatically creates order-token columns and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one Redshift database and schema, one staging bucket and prefix, one IAM role, and one source feeding a single raw table.

Redshift is a bad fit when the team does not want to own staging infrastructure, or when another warehouse already has better organizational gravity than AWS-based analytics.