Skippr Docs

Appearance

What Network or Staging Access Synapse Needs ​

July 2026

Synapse destination access is a direct TDS connection plus a login that can create and write objects in the target schema.

Short Answer ​

Azure Synapse needs a working connection string and a runner that can reach the Synapse endpoint over the configured TDS connection. The destination docs define the connector around connection_string and schema, so the practical boundary is one SQL endpoint plus one schema that the configured login can write to.

That makes the first validation straightforward. If the destination is dbo, the runner must be able to open the Synapse connection with the exact DSN in SYNAPSE_CONNECTION_STRING, and the login has to create or update objects in dbo. When CDC is enabled, the same warehouse path then has to support MERGE-based final-state application with _skippr_order_token and tombstones.

Why Teams Struggle with This ​

Synapse setup usually fails because the connection string is only half right or the login reaches the database but not the schema boundary you planned to use. Those are load-path problems, not abstract platform problems.

  • The runner must reach the Synapse endpoint over the configured TDS connection.
  • The login named in the connection string needs write access to the target schema.
  • A valid database login does not help if the DSN points at the wrong server or database.
  • CDC relies on MERGE semantics, so the destination path must be able to create and maintain the managed tables cleanly.

How Skippr Handles It ​

Skippr keeps Synapse direct by using one connection string and one schema. That gives operators a clear warehouse boundary to validate from CI, a container, or a private runner without introducing an extra staging service that the docs do not require.

It also keeps the CDC story compact. Once the TDS path and schema permissions are correct, Skippr can apply the documented MERGE model with order tokens and tombstones, so the same warehouse path covers both initial loading and final-state change application.

  • Uses one ADO-style Synapse connection string as the load boundary.
  • Targets one explicit schema, dbo by default.
  • Requires straightforward schema write permissions rather than a separate object-store staging layer.
  • Supports CDC final-state MERGE behavior with automatic order-token and tombstone support.

What the First Useful Version Looks Like ​

The first useful version is one Synapse DSN, one target schema, and one small table load that proves the endpoint, login, and schema privileges are aligned.

If that small load is still unreliable, fix the DSN and schema grants first. Synapse gets much simpler once the direct warehouse boundary is settled.