2 posts tagged with "SQL Server"

You want to try Supaflow against a SQL Server that runs on your own machine -- a developer install on your laptop or a server on your office network. There is no public IP, no port forwarding, and no VPN between that database and the cloud. A Supaflow-hosted Agent needs to reach the database over the network, so localhost in the datasource form will not work for this test.

A TCP tunnel is the fastest way to prove connectivity during a proof of concept (POC). This guide shows two temporary options: ngrok, the popular managed tunneling service, and bore, a minimal open-source alternative that needs no account. Both give you a public host and port that forward straight to your local SQL Server, and both plug into the Supaflow datasource form the same way.

For production pipelines, deploy a self-hosted Docker Agent on a stable host inside the same private network as SQL Server. The agent connects to SQL Server over the local network and polls Supaflow over outbound HTTPS, so the database port stays private. This removes the tunnel relay and changing public endpoint from the data path and gives long-running pipelines a predictable network path.

Need to replicate your SQL Server tables into Snowflake? Supaflow's SQL Server connector supports two query modes: Standard for simple cursor-based sync, and Change Tracking for capturing every insert, update, and delete -- including hard deletes that standard mode can never detect.

This guide walks through setting up a SQL Server to Snowflake pipeline with Change Tracking enabled, so your Snowflake tables stay in sync with every change made in SQL Server.