Skippr Docs

Appearance

What Access Skippr Needs to Write to Synapse ​

June 2026

Synapse write access is simple on paper, but the login still has to own the schema-level write boundary that Skippr depends on.

Short Answer ​

Skippr needs an ADO-style Synapse connection string plus a login that can write to the target schema, and the runner must be able to reach the Synapse endpoint over the configured TDS connection. The docs keep the requirement narrow: the login has to create and write objects in the chosen schema, which defaults to dbo unless you set something more specific.

That becomes especially important when CDC is enabled. Synapse uses MERGE for final-state reconciliation and Skippr adds _skippr_order_token columns plus tombstone tables automatically, so the warehouse identity is being asked to maintain managed tables, not just append rows into a staging area.

Why Teams Struggle with This ​

Synapse write problems often look like connection-string issues even when the server and password are correct. The login may authenticate and still fail because the target schema is wrong or because the identity cannot create and write the objects Skippr manages there.

  • The connection string must point at the correct Synapse endpoint and database.
  • The login needs write access to the target schema, including object creation where Skippr will manage tables.
  • The runner must be able to reach the TDS endpoint from its network environment.
  • CDC uses MERGE, so the warehouse identity has to support table updates as part of the normal write path.

How Skippr Handles It ​

Skippr keeps Synapse access straightforward by asking only for the connection string and target schema. That is helpful because Azure teams can reason directly from the existing Synapse login and schema design instead of translating the connector into a second permission vocabulary.

The CDC destination docs then make the operational model clear. Synapse applies final-state mutations with MERGE and manages order-token plus tombstone tables automatically, so the warehouse login needs durable write authority over the schema Skippr owns.

  • Uses one connection string for Synapse connectivity.
  • Needs explicit write access on the target schema.
  • Writes over the normal TDS connection path to the Synapse endpoint.
  • Uses MERGE, order tokens, and tombstones for CDC-managed final-state tables.

What the First Useful Version Looks Like ​

The first useful version is one database, one schema, and one service login that can create and update the raw tables Skippr owns there.

If the first run authenticates but fails on table creation or update, treat that as a schema privilege problem first because that is where the Synapse write boundary usually breaks.