How Synapse Shapes the Warehouse Contract

July 2026

Synapse is a clear warehouse contract when the team wants current-state SQL tables in one schema and is willing to make the MERGE-based CDC rules part of the destination design.

Short Answer

Azure Synapse shapes the warehouse contract around the target schema and the TDS-connected tables created there. The destination docs describe a simple connector surface: connection_string plus schema. The CDC docs supply the real table behavior. Skippr applies changes with MERGE, adds _skippr_order_token NVARCHAR(4000), and creates tombstone tables so stale writes and stale inserts do not override newer row state.

That means the contract looks familiar to downstream SQL users. If the destination is dbo.orders, consumers query dbo.orders as the current-state table keyed by the business key. They do not need to rebuild current state from an append-only mutation stream. The important thing is that the team understands the table stays correct because Synapse can run the guarded MERGE logic behind the scenes.

Why Teams Struggle with This

Synapse contracts are often underspecified because the connector appears simple. A connection string and a schema are enough to connect, but they are not enough to explain how the destination table behaves under retries, updates, and deletes.

• A valid connection string can still point at the wrong database or login for the schema that is supposed to hold the contract.
• Using the default dbo schema by habit can make ownership unclear if the team never intended it as the raw landing boundary.
• If reviewers never talk about _skippr_order_token or tombstone tables, they are not really describing CDC correctness.
• The warehouse login needs create and write access in the target schema or the table contract never becomes real.

How Skippr Handles It

Skippr keeps Synapse direct because the destination surface is almost exactly the warehouse choice you need to make: one connection string and one schema. That simplicity is useful when the team is disciplined enough to define the landing area and keep credentials out of source control.

The CDC behavior is also easy to explain once it is named. Synapse tables remain the main interface, while MERGE enforces newer-wins updates and tombstone tables keep delete order intact during retries and replays.

• Targets a specific Synapse schema over the documented TDS connection path.
• Keeps authentication in one environment-backed connection string.
• Uses MERGE with _skippr_order_token for CDC final-state reconciliation.
• Creates tombstone tables automatically so delete safety is part of the warehouse contract.

What the First Useful Version Looks Like

The first useful version is one schema such as dbo and one CDC-managed table whose business key the team can test with inserts, updates, and deletes. That makes the Synapse contract concrete right away.

If the schema choice is still accidental or the login privileges are broader than needed, tighten that before the contract spreads to more tables. Synapse is easiest to support when the landing schema is intentional and narrow.