Skippr Docs

Appearance

When to Use Synapse as a Warehouse Destination ​

June 2026

Synapse is the right warehouse destination when the team wants current-state tables on a familiar SQL surface with schema-based control and MERGE-driven reconciliation.

Short Answer ​

Use Azure Synapse as a warehouse destination when the team wants a familiar SQL surface, one durable ADO.NET connection string, and schema-based control over where raw or bronze tables land. It is a strong fit when the destination schema is a place where Skippr can create and update objects and when MERGE-based final-state CDC is more useful than a hand-built replay policy.

A good example is a team landing operational tables into a Synapse schema such as dbo so downstream SQL users can work from current-state rows. Skippr can connect through the configured connection string, write into the chosen schema, and keep CDC-managed tables current through MERGE with order tokens and tombstone protection.

Why Teams Struggle with This ​

Synapse is a sensible choice when the team wants SQL-first warehouse access and can manage the connection string, schema permissions, and network path cleanly. It becomes a bad fit when those basics are uncertain, because the destination contract is only as strong as the schema and connection setup behind it.

  • The login behind the connection string needs write access to the target schema before anything useful can land.
  • The machine running Skippr has to reach the Synapse endpoint over the configured TDS connection.
  • The connection string is effectively the control plane, so teams need to manage it carefully through environment variables rather than static config.
  • If analysts and model authors do not already center their work on Synapse, the warehouse choice may add more friction than value.

How Skippr Handles It ​

Skippr keeps the Synapse destination focused on the real setup boundary: one connection string and one schema. That makes it a good fit for organizations that already treat Microsoft SQL-style connectivity as routine operational plumbing.

CDC support then adds the part many teams would otherwise have to build themselves. Skippr uses MERGE-based final-state reconciliation with automatic _skippr_order_token columns and tombstone tables, so Synapse can stay current without ad hoc replay logic.

  • Connects to Synapse through an ADO.NET-style 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 source feeding a table that downstream SQL users can validate easily.

Synapse is a bad fit when schema permissions and network access are too uncertain to make the landing zone dependable, or when a different warehouse offers a clearer operational model for the team.