Skippr Docs

Appearance

How to Review Synapse Warehouse Config Before Production ​

July 2026

Synapse review starts with the connection string and schema boundary, then confirms that the team expects final-state CDC tables rather than a raw mutation log.

Short Answer ​

Review a Synapse warehouse config by checking the connection_string and schema first. The production question is whether that ADO-style connection string really points at the intended Synapse database and whether the login can create and write objects in the target schema over the documented TDS connection path.

After that, review the CDC contract. The destination docs describe Synapse as a MERGE-based final-state warehouse, and the CDC destination docs add the important details: Skippr writes _skippr_order_token values, records tombstones, and uses newer-wins reconciliation so a replayed older update or insert does not replace a newer row state that is already present.

Why Teams Struggle with This ​

Synapse reviews often stop at "the connection string works." That is not enough for production. The team still needs to verify schema-level write access and explain the warehouse as a current-state CDC destination instead of a place where every mutation is stored as the primary interface.

  • The connection string should be reviewed as a real contract because it defines server, database, user, and password behavior together.
  • The selected schema, which defaults to dbo, should be intentional rather than inherited by habit.
  • The login needs create and write access in the target schema before the first warehouse load can succeed.
  • CDC review should include Synapse MERGE behavior plus the order-token and tombstone structures that protect final state.

How Skippr Handles It ​

Skippr keeps Synapse review simple because the connector surface is small: one connection string and one schema. That clarity helps teams ask the right production questions early.

The CDC side stays inspectable as well. Skippr manages _skippr_order_token columns and tombstone tables automatically, then relies on Synapse MERGE semantics so row freshness is resolved in the destination instead of in downstream cleanup SQL.

  • Uses an ADO-style connection string for warehouse connectivity.
  • Targets a specific schema, with dbo as the default.
  • Writes through the Synapse TDS connection path.
  • Supports final-state CDC with MERGE, order tokens, and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one schema, one validated login, and one CDC-managed table that proves Synapse can accept writes and maintain current state the way the team expects.

If the warehouse story is still "we will figure out CDC semantics later," pause there. In Synapse, as in every other destination here, the review should settle correctness before volume.