Skippr Docs

Appearance

How to Explain Redshift Tables to Analysts ​

July 2026

Analysts should treat Skippr Redshift tables as current-state Redshift tables, not as S3 staging files or a record of every incoming mutation.

Short Answer ​

Explain Redshift tables as ordinary warehouse tables in the target schema that hold current-state raw rows after each load completes. Skippr stages files in S3 and uses COPY plus merge logic behind the scenes, but analysts should think in table terms: public.customers is the current customer row set, not a pile of staged files or a log of change events.

That framing is especially useful for freshness. Redshift tables update as loading and merge work completes in batches. If a customer record changed three times upstream, the analyst-facing raw table should show the latest row after the current run finishes. _skippr_order_token and tombstone handling exist to make that current-state view reliable under retries and deletes.

Why Teams Struggle with This ​

Teams often over-explain the Redshift load path and under-explain the resulting table behavior. Analysts do not need to start with S3 prefixes and IAM roles. They need to know what one row means, when it refreshes, and whether the table is current state or history.

  • S3 staging is part of how data lands, but it is not the surface analysts should query to understand the warehouse.
  • A CDC-managed Redshift table is usually a latest-row table, not a replay log of all upstream mutations.
  • The _skippr_order_token column is an ingestion safety field, not a business event sequence.
  • Cluster versus workgroup settings matter for operations, while the analyst contract is still just the target schema table and its row meaning.

How Skippr Handles It ​

Skippr helps by keeping the operational parts explicit in config while leaving the warehouse result conventional. Engineering can see the staging bucket, prefix, IAM role, and Redshift endpoint details, while analysts can work with normal Redshift tables.

The final-state CDC behavior is also consistent with ordinary warehouse expectations. After Skippr stages and merges, analysts see one current row per key rather than having to reconstruct state from raw mutations themselves.

  • Loads Redshift through the documented S3 staging plus COPY workflow.
  • Uses staging-table merge semantics for exactly-once final-state CDC.
  • Automatically adds _skippr_order_token columns to CDC-managed tables.
  • Creates tombstone tables so delete handling stays correct across retries and replays.

What the First Useful Version Looks Like ​

The first useful explanation is one table with a known key and one note about freshness: this table updates after the load cycle completes and shows the latest row for each key. That gives analysts a stable starting point.

If the team needs change history later, build that intentionally. The Redshift raw table is most useful when it stays a clear current-state contract instead of a mixed-purpose artifact.