How to Configure Synapse as a Warehouse Destination
May 2026
Synapse warehouse setup is mostly about a correct connection string, a writable schema, and making sure the runner can reach the TDS endpoint.
Short Answer
Configure Azure Synapse by setting warehouse.kind to synapse, then passing connection_string and the target schema, which defaults to dbo if you do not override it. The connection string should live in SYNAPSE_CONNECTION_STRING so the connector config stays free of secrets and can move between environments more easily.
A clean first setup is one database login with write access to the target schema and a connection string that names the correct server, user, password, and database. Because the connector uses the TDS protocol, the practical check is not only whether the credentials look valid, but whether the runner can actually reach the Synapse endpoint from the network where Skippr will run.
Why Teams Struggle with This
Synapse warehouse problems usually come from either connection-string detail or schema rights. Teams can authenticate to the server and still fail on table creation, or they can have the right login but discover the runtime host is blocked from reaching the TDS endpoint altogether.
- The connector depends on a valid ADO.NET-style connection string in
SYNAPSE_CONNECTION_STRING. - The target login needs write access to the chosen schema.
- The runner must be able to reach the Synapse endpoint over TDS from its actual network location.
- A default schema like
dbois convenient, but a dedicated raw schema is often cleaner once multiple integrations are active.
How Skippr Handles It
Skippr keeps Synapse configuration concise by accepting the same connection-string style most Azure SQL and Synapse operators already use. That helps because the fastest way to troubleshoot the connector is usually to inspect one concrete connection string and one schema target, not to reverse-engineer a long parameter list.
The first successful load should give a clear signal that the warehouse is ready. Skippr can connect through TDS, write into the intended schema, and keep the destination stable enough that later CDC-managed tables can build on the same warehouse definition.
- Simple Synapse warehouse config with
connection_stringandschema. - Secret handling through
${SYNAPSE_CONNECTION_STRING}. - Alignment with the TDS connectivity model described in the docs.
- A clean landing zone for both initial loads and later CDC final-state tables.
What the First Useful Version Looks Like
Before rollout, test the connection from the actual runtime environment so firewall rules or private-network assumptions do not hide behind a locally successful login.
If this warehouse will host several sources, choose a schema ownership model early instead of letting all integrations accumulate in a generic shared namespace.
