Overview & Value
The Openflow SQL Server connector is Snowflake's native way to bring Microsoft SQL Server data into Snowflake continuously. It reads change history at the source, applies it to Snowflake, and keeps your analytics tables current, without a third-party pipeline in the middle.
What it does
You point one connector at a SQL Server instance. It discovers the databases, snapshots the tables you select, then streams every subsequent INSERT, UPDATE, and DELETE into Snowflake in near real time. Each source database lands in its own Snowflake schema, so a multi-database instance stays cleanly separated on the destination side. Replication runs on an Openflow runtime, either Snowflake-managed or in your own cloud (BYOC on AWS) when you need to own the networking.
Why teams choose it
01 Snowflake-native path
Data lands directly in Snowflake under Snowflake governance. There's no third-party staging layer to secure, monitor, or pay for.
02 Lower cost on high volume
A strong fit where row-based or per-connector ETL pricing gets expensive as database replication volume grows.
03 Near real-time
Selected tables replicate continuously into Snowflake within seconds of the source change, not on a nightly batch.
04 CT or CDC, your choice
Change Tracking for lightweight current-state sync, or Change Data Capture for full row-level history. Compare the modes →
05 Multi-database per instance
One connector replicates every database on the instance into separate destination schemas, with no connector sprawl.
06 Managed or BYOC
Run on Snowflake-managed Openflow, or bring-your-own-cloud on AWS when you need to control placement and egress.
The pain it removes
How it compares
A rough guide for positioning against the common alternatives. The right choice depends on volume, latency needs, and how much of your source is databases versus SaaS apps.
| Openflow SQL Server | Fivetran / SaaS ETL | Custom / DIY CDC | |
|---|---|---|---|
| Where data lands | Directly in Snowflake | Vendor stage, then Snowflake | Wherever you build it |
| Cost model | Snowflake compute you own | Per active row / MAR | Engineering time + infra |
| Latency | Near real-time | Minutes to hours (by plan) | Whatever you engineer |
| Governance | Snowflake-native | Split across vendor + Snowflake | Your responsibility |
| Connector breadth | SQL Server here; Openflow has a growing SaaS + database catalog | Broad SaaS + database catalog | Anything you build |
| Day-2 ownership | Snowflake-managed option | Fully managed | High |
Is it the right fit?
Great fit
- High-volume SQL Server replication where ETL row/connector pricing hurts
- Teams that want Snowflake-native governance, not a third-party stage
- Near real-time analytics on operational data
- Multi-database or multi-tenant SQL Server estates
- Audit / history needs (with CDC) or current-state sync (with CT)
Consider alternatives when
- Your source isn't SQL Server, so reach for the matching Openflow connector instead
- You want the lowest possible day-2 operational touch
- Source tables lack primary keys (required for replication)
- You need auth beyond username/password today
Use Cases
Where the Openflow SQL Server connector earns its place. Each scenario below notes whether it leans on Change Tracking (current state) or CDC (full history); see CT vs CDC for the distinction.
Operational reporting & EDW sync
Keep the enterprise data warehouse continuously in sync with the SQL Server systems of record, so dashboards reflect operations minutes ago instead of last night.
Why this connector: current-state sync with minimal source overhead, landing straight into governed Snowflake tables.
Medallion bronze ingestion
Feed the bronze layer of a medallion architecture with raw, continuously-updated SQL Server data, then build silver/gold with dbt or Dynamic Tables on top.
Why this connector: full change history at bronze preserves fidelity for downstream transformation and reprocessing.
ETL cost takeout
Replace or offload row-priced third-party ETL for high-volume database replication, moving the spend onto Snowflake compute you already own and govern.
Why this connector: no per-active-row pricing and no third-party stage to license or secure.
High-volume OLTP replication
Mirror busy transactional databases into Snowflake for analytics without hammering the production OLTP instance with reporting queries.
Why this connector: change-log replication offloads analytical read load from the source system.
Audit, history & SCD
Retain a complete record of how rows changed over time for compliance, audit trails, slowly-changing dimensions, and point-in-time analysis.
Why this connector: CDC carries before/after values, so history is reconstructable in Snowflake.
Multi-database consolidation
Bring every database on a SQL Server instance, or a multi-tenant estate, into Snowflake under one connector, each in its own destination schema.
Why this connector: one runtime, one connector covers the whole instance instead of one pipeline per database.
Common across industries
The same pattern, operational SQL Server data made analytics-ready in near real time, recurs wherever SQL Server backs the business.