Change Tracking vs CDC
The SQL Server connector ships in two variants, built on two different SQL Server features. Both replicate into Snowflake. The difference is how much change history the source captures, and therefore how much you can reconstruct on the Snowflake side.
A lightweight SQL Server feature that records which rows changed and the operation type, but not the intermediate values. The connector reads the change set and merges current row state into Snowflake.
- Tracks changed keys + operation, not column-by-column history
- Cheaper to run on the SQL Server side
- Snowflake reflects the latest state of each row
- Requires a primary key on each replicated table
A heavier SQL Server feature that records every row-level change with before/after values to change tables. The connector replays that log, so Snowflake can hold full history.
- Captures INSERT / UPDATE / DELETE with column detail
- Higher storage + overhead on the SQL Server side
- Enables audit, slowly-changing dimensions, point-in-time
- Requires CDC enabled on the source database and tables
Side by side
| Change Tracking | Change Data Capture | |
|---|---|---|
| What's captured | Changed rows + operation type | Full row-level changes with before/after values |
| History on Snowflake | Latest state per row | Complete change history |
| Source overhead | Lower | Higher (change tables + capture jobs) |
| Storage on source | Minimal | Larger (retained change tables) |
| Primary key | Required | Required |
| Best for | Current-state analytics, cost-sensitive sync | Audit, SCD, point-in-time, compliance |
Which should you pick?
Choose Change Tracking when
- You need the current state of the data, not its full history
- You want the lightest possible footprint on SQL Server
- You're cost-sensitive on source overhead and storage
- Analytics care about "what is true now," not "what changed when"
Choose CDC when
- You need an audit trail or regulatory history
- You're building slowly-changing dimensions or point-in-time views
- You want before/after values for every change
- The extra source overhead is an acceptable trade for fidelity
Both variants require a primary key on every replicated table. It's how the connector identifies rows to merge. Tables without a primary key can't be replicated and are skipped during discovery.
Single-database vs Multi-database
The Change Tracking connector ships as two flow packages in the Openflow connector registry. Both replicate SQL Server into Snowflake using Change Tracking. The difference is topology: how many source databases one connector instance owns, and how it names the destination objects.
One connector instance replicates one database. The JDBC URL pins a
specific databaseName, and the flow manages objects at the database level.
- JDBC URL includes
databaseName=your_database - Plain processors: CaptureChangeSqlServer, FetchTableSnapshot, MergeSnowflakeJournalTable, UpdateSnowflakeDatabase
- Required shape for Azure SQL Database (single-database PaaS)
- One connector per database keeps a small blast radius
One connector instance points at the SQL Server instance and discovers many databases, routing each into its own destination schema.
- JDBC URL points at the instance; the connector discovers databases
- Three-part
database.schema.tablenames viaDestination Schema Pattern+${source.database.name} - MultiDatabase* processors, plus EnforceOrder, UpdateSnowflakeSchema, and SetAttributesValidatingReferences
- The shape used by the reference implementation, which runs RetailDB, PaymentsDB and BillingDB on one instance
Side by side
| Single-database (sqlserver) | Multi-database (sqlserver-multidatabase) | |
|---|---|---|
| Databases per instance | One database per connector instance | Many databases discovered from one instance |
| JDBC connection URL | Pinned to a database via databaseName | Points at the instance; databases are discovered |
| Destination naming | Database-level objects | Three-part db.schema.table via Destination Schema Pattern and ${source.database.name} |
| Distinct processor types | CaptureChangeSqlServer, FetchTableSnapshot, MergeSnowflakeJournalTable, UpdateSnowflakeDatabase | MultiDatabase* variants, plus EnforceOrder, UpdateSnowflakeSchema, SetAttributesValidatingReferences |
| Total processors | 52 (Incremental 17 + 5, Snapshot 5 + 21, Staleness 4) | 59 (Incremental 19 + 6, Snapshot 5 + 25, Staleness 4) |
| Azure SQL Database (single-DB PaaS) | Use this: one connector per database | Not applicable for single-DB PaaS |
| Change detection | SQL Server Change Tracking | SQL Server Change Tracking |
| Primary key | Required | Required |
| Best for | A single database, or per-database isolation | Many databases on one instance, multi-tenant, per-BU or per-region fleets |
Which should you pick?
Choose single-database when
- You only need to replicate one source database
- Your source is Azure SQL Database, the single-database PaaS offering
- You want per-database isolation and a smaller blast radius
- You prefer the simplest possible connector configuration
Choose multi-database when
- One SQL Server instance hosts several databases you want to replicate
- You run multi-tenant workloads with one database per tenant
- You want one connector to discover and route many databases into per-database schemas
- You are following the reference implementation, which replicates RetailDB, PaymentsDB and BillingDB from a single instance
Both are the same Change Tracking connector and both require a primary key on
every replicated table. The choice is topology, not change-detection method. Verified exports
of both flows are vendored under connector-flow/ in the
reference implementation repository.