SQL SERVER → SNOWFLAKE
Replicate SQL Server tables into Snowflake with Change Tracking — captures every insert, update, and hard delete that timestamp-based pipelines miss.
Choose column-based incremental sync for simple tables, or SQL Server Change Tracking when you need inserts, updates, and hard deletes. Supaflow also preserves SQL Server-specific types like datetimeoffset, money, hierarchyid, and geography, and recovers cleanly when Change Tracking retention windows expire. Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume.
Used by data engineering teams running Microsoft-stack SaaS, retail OMS, and Azure-hosted fintech workloads that need SQL Server data in Snowflake with full delete capture — with no per-row fees.
Every row below is an actual capability in the SQL Server connector, not a forward-looking promise.
| Feature | How it works | Limit / caveat |
|---|---|---|
| Sync modes | Use column-based incremental sync for straightforward insert/update capture, or SQL Server Change Tracking for insert, update, and hard-delete capture. | The sync mode is selected per source. To mix Change Tracking for transactional tables with column-based sync for reference tables, configure separate sources. Change Tracking requires SQL Server 2008+ with Change Tracking enabled at the database and table level, and each tracked table must have a primary key. |
| Delete capture | When Change Tracking is enabled, deleted source rows are carried into Snowflake as soft-delete records so downstream models can filter, reconcile, or hard-delete deliberately. | — |
| Change Tracking recovery | Supaflow tracks the last successful SQL Server change version and reads only later changes on the next run. | If SQL Server expires the required Change Tracking history before the next run, Supaflow detects the stale baseline and performs a clean resnapshot instead of silently missing changes. |
| Pagination / chunking | Initial snapshots and full-table reads are chunked by primary key so large tables do not rely on fragile offset scans. Change Tracking runs read each committed change window in a deterministic order. | If a run fails during a change window, the next run safely replays that window from the last committed boundary and merges by primary key in Snowflake. |
| SQL Server type handling | SQL Server-specific types are handled intentionally: datetimeoffset keeps timezone context, money and smallmoney keep precision, rowversion stays binary, and hierarchyid, geometry, and geography land as readable strings. | — |
| Authentication & TLS | SQL authentication is supported, with plaintext, TLS, and strict TLS options. Advanced connection properties are available for environments that need custom SQL Server settings. | — |
| Connection pooling & retry | Transient deadlocks, lock timeouts, Azure SQL throttling, failover, and service-busy errors are retried automatically. Permission and configuration errors fail fast so operators can fix the source. | — |
| Schema discovery | Supaflow discovers tables, columns, and primary keys automatically, normalizes database-name casing from the server, and warns when a table cannot participate in Change Tracking because prerequisites are missing. | — |
| Destination | Lands directly in Snowflake with generated tables, Snowflake-ready types, primary-key-based incremental merges, and soft-delete handling for Change Tracking sources. | — |
Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees.
Most timestamp-based pipelines lose deletes because deleted rows no longer exist to be queried. Supaflow uses SQL Server’s native Change Tracking to capture every insert, update, and hard delete, with automatic recovery when retention windows expire. Deleted rows land in Snowflake with soft-delete metadata you can use or ignore.
Datetimeoffset keeps timezone context. Money keeps precision. Hierarchyid, geometry, and geography come through as readable values instead of raw bytes. The connector handles SQL Server’s specifics so your Snowflake schemas don’t need to.
Every one of these is something our connector handles specifically. A generic pipeline built in Airflow or a basic ELT tool will hit at least three of them in production.
Failure mode: Change Tracking retention has a configurable window. If a backfill or outage exceeds that window, SQL Server can no longer provide the change history required for the next incremental run. Naive pipelines stall or silently miss data.
Evidence: Reproduced against Azure SQL where the default 2-day CT retention is shorter than common backfill durations for tables with millions of rows.
Fix: Supaflow detects the stale Change Tracking baseline, starts a clean resnapshot from the current source state, and continues without requiring manual state repair.
Failure mode: SQL Server’s `timestamp` and `rowversion` types are 8-byte binary row-version markers, not date/time values. Pipelines that map them to a date/time column corrupt the data on landing.
Evidence: Documented Microsoft naming legacy that has tripped data engineers for two decades.
Fix: Supaflow keeps both as binary row-version values instead of converting them into timestamps.
Failure mode: Some SQL Server-specific types can arrive at generic pipelines as unreadable binary payloads. Passing those bytes through makes the Snowflake table hard to query.
Evidence: Reproducible against SQL Server tables that use hierarchyid, geometry, or geography columns.
Fix: Supaflow converts these values into readable string forms before loading them to Snowflake.
Failure mode: Azure SQL Database can throttle, fail over, or report service-busy conditions under load. A retry-on-everything strategy masks permanent errors; a no-retry strategy fails during normal managed-database turbulence.
Evidence: Documented Azure SQL behavior; verified in production against shared-tier and elastic-pool databases.
Fix: Supaflow retries transient SQL Server and Azure SQL conditions with backoff while failing fast on permanent permission, schema, and configuration errors.
Failure mode: If the user enters `myDB` in the connector config but the SQL Server instance reports `MyDb`, schema discovery can produce duplicate database entries differing only in case, polluting downstream metadata.
Evidence: Common against case-insensitive collations where the surface and the metadata casing diverge.
Fix: Supaflow uses the database casing reported by SQL Server so the same source does not appear under duplicate names.
Provide host, port, database name, and credentials. Choose plaintext, TLS, or strict TLS, and add advanced connection properties if your SQL Server environment needs them.
SQL Server source docs→Choose column-based incremental sync for insert/update capture, or Change Tracking for inserts, updates, and hard deletes. To run both modes against the same database, configure separate sources.
Connect your Snowflake warehouse. Tables are created with Snowflake-ready types, primary keys flow through, and Change Tracking sources include soft-delete metadata.
Snowflake destination docs→Run on a cron or interval schedule. Change Tracking reads changes since the last successful run; column-based incremental sync reads rows past the last saved value.
Schedules docs→Supaflow reads SQL Server tables and lands them in Snowflake with generated tables, primary keys, and Snowflake-ready types. Choose column-based incremental sync for simple insert/update capture, or SQL Server Change Tracking when you need inserts, updates, and hard deletes. To mix modes, configure separate sources against the same database.
Yes, when Change Tracking is enabled on the source table. Deleted rows land in Snowflake with soft-delete metadata, so downstream consumers can filter, reconcile, soft-delete, or hard-delete as needed. Column-based incremental sync cannot capture deletes because deleted rows no longer exist to be queried.
If SQL Server expires the Change Tracking history needed for the next incremental run, Supaflow detects the stale baseline and starts a clean resnapshot from the current source state. That avoids silent data loss and removes the need for manual state repair.
Yes. Supaflow handles Azure SQL throttling, failover, and service-busy conditions with automatic retry and supports strict TLS for compliance-sensitive deployments. Both single database and elastic pool topologies are supported.
Fivetran and Hevo often price by rows or changed-record volume — a high-churn transactional table can spike your bill mid-month, especially when change tracking captures every update on top of inserts. Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees. See the pricing page for the credit packages and free tier.
Hierarchyid, geometry, and geography land as readable string values instead of opaque bytes. Datetimeoffset keeps timezone context, money and smallmoney keep precision, and timestamp/rowversion stay as binary row-version markers rather than being treated as dates.
Yes. The sync agent runs in your own VPC if you want SQL Server credentials and row content to stay in your network. The control plane is managed; the data plane can be managed or self-hosted.
The SQL Server source and Snowflake destination, plus other Supaflow connectors you can pair into a Snowflake pipeline.
Source connector overview and capabilities.
Destination connector overview and capabilities.
For Postgres-side replication into Snowflake.
Pair with SQL Server for cross-system analytics in Snowflake.
Pair with SQL Server when CRM and transactional data join in Snowflake.
Browse the full catalog of sources and destinations.
Connection setup, encryption modes, CT prerequisites, query mode selection, and troubleshooting.
Connect your Snowflake warehouse, role requirements, type mapping, and sync semantics.
Long-form walkthrough showing CT setup and the full pipeline end-to-end.
Every connector is included on every plan. Pay only for compute consumed (Supaflow Credits).
Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume. Change Tracking captures inserts, updates, and hard deletes; Supaflow recovers from expired Change Tracking history and preserves SQL Server-specific types.