Skippr Docs

Appearance

How to Explain Synapse Tables to Analysts ​

July 2026

Analysts should view Skippr Synapse tables as ordinary schema-qualified current-state tables, not as an operational log of the TDS loading path.

Short Answer ​

Explain Synapse tables as current-state tables in the configured schema, usually something like dbo, where each business key resolves to the latest raw row after the current load finishes. Skippr writes through the TDS connection and uses MERGE for CDC, so the meaningful analyst contract is the table content after that merge, not the mechanics of the connection string.

That means a table such as dbo.accounts should be described in straightforward warehouse terms. If an account status changes upstream, analysts should expect dbo.accounts to show the latest status after the successful run. _skippr_order_token and tombstone handling exist so old events and deletes are applied safely, but analysts usually only need to know that the main table is the current raw state.

Why Teams Struggle with This ​

Synapse tables are easy to mis-explain because the operational setup is connection-string heavy. That setup matters for engineering, but analyst trust comes from a much simpler statement about what one row means and when it becomes current.

  • The target schema defines where raw tables land, but the row meaning still needs to be stated explicitly as current state or history.
  • A CDC-managed Synapse table is generally the latest row per key, not a mutation log.
  • The connection string is operational configuration, not part of the table meaning analysts should reason from.
  • The _skippr_order_token column and tombstone tables are system-level correctness tools rather than primary analytical inputs.

How Skippr Handles It ​

Skippr keeps the Synapse destination narrow enough that the explanation can stay clean. Engineering manages one connection string and one schema, while analysts interact with ordinary SQL tables that behave like a current-state raw landing layer.

The CDC semantics also support a plainspoken explanation. Synapse uses MERGE, and Skippr adds order-token and tombstone protections automatically, so the table contract can stay focused on latest rows instead of replay edge cases.

  • Connects to Synapse through one ADO.NET-style connection string.
  • Targets a named schema such as dbo.
  • Uses MERGE for exactly-once final-state CDC reconciliation.
  • Automatically creates _skippr_order_token columns and tombstone tables.

What the First Useful Version Looks Like ​

The first useful explanation is one schema-qualified table with one known business key. Tell analysts that the table shows the latest raw row for that key after the last completed run, and note that the extra Skippr field is internal.

If a team later needs history, separate that conversation from the raw Synapse table. The landing table is easiest to trust when its purpose stays simple and current-state oriented.