Skippr Docs

Appearance

Common Synapse Warehouse Setup Mistakes ​

May 2026

Synapse warehouse setup often goes wrong because teams treat the ADO.NET connection string as the whole story and forget the schema and final-state contract it needs to support.

Short Answer ​

The most common Synapse warehouse mistakes are using a connection string that reaches the wrong database, assuming the login can create objects in the target schema, and expecting CDC to behave like unguarded last-write-wins loading. Skippr expects an ADO-style connection_string and target schema, then applies CDC with MERGE statements, _skippr_order_token, and tombstone tables for final-state correctness.

In practice, that means the first successful login is not enough proof that the warehouse is ready. A connection string may authenticate while still landing you in the wrong database, and a login may reach dbo but lack the ability to create or update the tables Skippr needs. Those mistakes appear late unless the warehouse review includes both connectivity and object-level write expectations.

Why Teams Struggle with This ​

Synapse setup is easy to under-specify because the connector surface is short. The docs make the real boundary clearer: the runner must reach the TDS endpoint, the login must have write access to the target schema, and CDC uses explicit MERGE-based reconciliation rather than hidden overwrite behavior.

  • ADO.NET connection strings can point at the wrong server or database while still looking syntactically valid.
  • Schema-level create and write permissions matter, not just the ability to authenticate to Synapse.
  • Teams often assume CDC will reconcile by arrival order even though Skippr compares _skippr_order_token values.
  • Delete correctness depends on tombstone tables as well as target-row deletion.

How Skippr Handles It ​

Skippr keeps the Synapse setup compact but explicit. The connector requires the connection string and schema you actually want to use, which makes warehouse reviews focus on the right thing: can this login create and write the objects needed in this database and schema?

For CDC, Skippr makes the reconciliation semantics inspectable. MERGE updates only when the incoming token is newer, and tombstones record deletes so stale replays cannot bring back removed keys.

  • Direct Synapse configuration through an ADO-style connection string and target schema.
  • CDC reconciliation through MERGE with _skippr_order_token guards.
  • Automatic tombstone tables for anti-resurrection delete handling.
  • A warehouse contract that stays visible instead of being scattered across manual SQL scripts.

What the First Useful Version Looks Like ​

A strong first version is one validated connection string, one dedicated target schema, and one login whose write scope has been tested there.

If CDC is part of the rollout, review one table’s merge key and delete path before adding more volume, because that is where final-state correctness is really decided.