Skippr Docs

Appearance

What a Good First Synapse Warehouse Setup Looks Like ​

July 2026

The smallest production Synapse destination is one env-backed connection string and one landing schema with clear write ownership.

Short Answer ​

A good first Synapse warehouse setup is one ADO-style connection string, one target schema, and one login that can create and write the tables Skippr needs over a reachable TDS connection. The docs keep the connector focused on connection_string and schema, which is a good signal that the smallest production version should be one clear landing area, not a warehouse-wide permission grab.

The first production boundary also needs to match CDC behavior. Synapse uses MERGE plus _skippr_order_token and tombstone tables for final-state reconciliation, so the destination login needs the schema-level authority to create and maintain those objects. If the connection string authenticates but the schema is not actually writable, the setup is not ready.

Why Teams Struggle with This ​

Synapse can look familiar to SQL Server teams, which sometimes leads them to underestimate the first production boundary. A successful destination still depends on the exact schema and TDS connectivity being correct.

  • The runner must reach the Synapse endpoint over the configured TDS connection before any warehouse design matters.
  • A valid login still fails if it cannot create or write objects in the chosen schema.
  • Treating the connection string as a normal config value spreads one secret across too many places.
  • If the first schema is not a deliberate landing zone, CDC-managed current-state tables become harder to own and reason about.

How Skippr Handles It ​

Skippr keeps Synapse practical by separating the visible warehouse boundary from the secret-bearing connection string. The schema stays reviewable, and the env-backed connection string stays out of the file.

That is exactly what a first production setup needs. One login, one schema, one place where raw tables land, and one documented MERGE-based CDC behavior that downstream users can rely on.

  • Uses connection_string: ${SYNAPSE_CONNECTION_STRING} for the secret-bearing value.
  • Keeps schema visible so the landing area is explicit.
  • Supports CDC through Synapse MERGE, order-token columns, and tombstone tables.
  • Works best with a dedicated login whose rights are scoped to the destination schema.

What the First Useful Version Looks Like ​

The first useful version is one Synapse endpoint, one env-backed connection string, and one schema such as dbo that the login can actually create and write tables in. That is enough to prove connectivity, auth, and warehouse ownership together.

If more schemas or environments are needed later, add them after one landing area is stable. A good first production destination is easy to explain and easy to support.