Skippr Docs

Appearance

When Redshift Is the Right Final-State Destination ​

July 2026

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

Short Answer ​

Redshift is the right final-state destination when the team wants a SQL warehouse in AWS and is comfortable treating S3 staging as part of the actual warehouse contract. The destination docs are specific about the pieces: database, schema, either cluster_identifier or workgroup_name, region, staging_s3_bucket, staging_s3_prefix, and iam_role_arn for the COPY flow.

The CDC docs then add the key reason to choose it for current-state loading: Skippr reconciles CDC through staging-table MERGE semantics with order-token guards and tombstones. That means Redshift is a good fit when you want a warehouse-native final-state table, not just staged files and a hope that downstream SQL will clean everything up later.

Why Teams Struggle with This ​

Redshift is a weak fit when the team wants the lightest possible setup and does not want to own staging infrastructure. The S3 bucket, prefix, IAM role, and warehouse permissions are not optional background details here. They are part of the destination design.

  • You need a staging S3 bucket and prefix before the documented COPY load flow can work.
  • Redshift must be able to assume the configured IAM role to read staged files.
  • The database user still needs write access to the chosen schema.
  • If the team wants a direct write target with minimal infrastructure around it, Redshift is usually heavier than necessary.

How Skippr Handles It ​

Skippr makes Redshift easier to choose deliberately because the connector exposes the staging controls instead of hiding them. The destination config mirrors the real operational boundary, and the CDC docs explain how merge-time order-token comparison preserves final state after retries or out-of-order mutation arrival.

That makes the design easier to review. Teams can evaluate the whole warehouse contract at once: S3 staging, warehouse permissions, and final-state reconciliation all belong in the decision.

  • Loads through the documented S3 staging plus COPY workflow.
  • Supports either a provisioned cluster or Redshift Serverless workgroup.
  • Uses staging-table MERGE semantics for exactly-once 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 CDC-managed table that downstream SQL users can treat as current truth.

If that staging design already feels like too much operational surface for the workload, another destination is probably the better fit.