Skippr Docs

Appearance

How Synapse Destination Authentication Works in Skippr ​

June 2026

Synapse destination authentication in Skippr is connection-string based, which keeps the warehouse config compact as long as the login, database, and schema write rights are all aligned.

Short Answer ​

Azure Synapse destination authentication in Skippr uses one ADO-style connection_string, usually supplied through SYNAPSE_CONNECTION_STRING, plus the target schema. That means the warehouse identity is the SQL login encoded in the DSN together with the specific Synapse database the connector will write to.

A normal example is Server=myserver.database.windows.net;User Id=admin;Password=secret;Database=mydb with schema dbo. The destination is only correctly authenticated when that login can connect over the configured TDS connection and create or write objects in the schema Skippr will manage.

Why Teams Struggle with This ​

Synapse auth can look deceptively simple because the connector asks for only a connection string and a schema. The docs make the practical requirement clear: the same login has to succeed as a database identity and as a warehouse writer, especially once CDC MERGE behavior enters the picture.

  • Authentication is DSN-based, so the server, database, login, and password all live inside one connection string.
  • The docs recommend environment interpolation for connection_string rather than storing it directly in config.
  • The Synapse login needs write access to the target schema, not merely connection rights.
  • CDC on Synapse uses MERGE, so the warehouse identity must support ongoing reconciliation work, not just a one-time connection test.

How Skippr Handles It ​

Skippr keeps the Synapse auth story compact and readable. One DSN names the warehouse identity, and one schema names the landing area. That is easy to review and easy to move between local testing and production once the runtime secret source is set.

It also lines up well with the CDC docs. The same identity that lands the first batch will later run MERGE-based reconciliation with _skippr_order_token and tombstone protection, so the destination user should be provisioned for that full behavior from the start.

  • Connection-string authentication through ${SYNAPSE_CONNECTION_STRING}.
  • A compact destination surface of one DSN plus one target schema.
  • A documented requirement that the Synapse login can create and write objects in that schema.
  • CDC support through MERGE with order-token and tombstone-table semantics.

What the First Useful Version Looks Like ​

The first useful version is one Synapse database, one writable schema, and one DSN tested from the same environment that will execute Skippr. That tells you whether the warehouse identity is production-ready.

If the destination will be shared with other workloads, create a role or login specifically for Skippr rather than reusing a broad administrative credential. Destination auth stays cleaner when ownership is explicit.