Skippr Docs

Appearance

When Synapse Is the Right Final-State Destination ​

July 2026

Synapse is the right final-state destination when the team wants a SQL-first warehouse on a Microsoft stack and can make the connection-string and schema boundary dependable.

Short Answer ​

Synapse is the right final-state destination when the team wants a familiar SQL-first analytical surface and one dependable ADO.NET connection string to define how Skippr reaches it. The destination docs keep the contract simple with connection_string and schema, while the CDC docs explain that final-state reconciliation happens through MERGE plus order-token and tombstone handling.

That is a good fit for organizations already oriented around Microsoft SQL tooling and schema-based control. If downstream users are comfortable in a Synapse SQL environment and the warehouse goal is current surviving rows rather than a custom replay framework, Synapse provides a straightforward place to land that final state.

Why Teams Struggle with This ​

Synapse is a weak fit when the team cannot make the connection-string and schema boundary reliable. Because the connector surface is intentionally small, uncertainty around TDS connectivity, schema write access, or login ownership shows up immediately.

  • The login behind the connection string needs write access to the target schema before anything useful can land.
  • The runner must reach the Synapse endpoint over the configured TDS connection.
  • The connection string becomes the practical control plane, so it has to be managed carefully through environment-backed config.
  • If analysts do not already work in Synapse or adjacent Microsoft SQL tooling, another warehouse may have more natural organizational gravity.

How Skippr Handles It ​

Skippr matches Synapse well because the destination design stays focused on the actual setup boundary. One connection string and one schema are enough to explain where data lands and who owns it.

The CDC docs then add the missing piece many teams would otherwise write themselves: MERGE-based final-state reconciliation with automatic order-token columns and tombstone tables. That keeps current-state correctness inside the destination instead of outsourcing it to downstream cleanup.

  • Connects through an ADO.NET-style Synapse connection string.
  • Targets a named schema such as dbo.
  • Supports exactly-once final-state CDC through MERGE.
  • Automatically manages order-token columns and tombstone tables.

What the First Useful Version Looks Like ​

The first useful version is one connection string, one writable schema, and one CDC-managed table that SQL users can validate immediately.

If the warehouse team cannot yet guarantee the schema and connectivity boundary, Synapse may be the eventual answer but not the right final-state destination to standardize on today.