SQLPro Sync vs Fabric Pipelines
SQLPro Sync is purpose-built for ongoing SQL Server → Fabric Warehouse replication. Microsoft Fabric Pipelines are a general-purpose ETL tool that can move data from many sources, including SQL Server, but require you to design and maintain the load logic yourself.
Use this page to decide which approach fits your situation.
Quick summary
- Choose SQLPro Sync when you need to keep SQL Server tables continuously up to date in Fabric with minimal engineering.
- Choose Fabric Pipelines when you need transformations, non-SQL-Server sources, tables without a primary key, or custom control over how inserts, updates, and deletes are applied to the target.
Feature comparison
| Feature | SQLPro Sync | Fabric Pipelines |
|---|---|---|
| Incremental change detection | Change Tracking - detects inserts, updates, and deletes without reading the full table | Must be designed manually: watermark columns, CDC, or full truncate-reload |
| Pipeline engineering required | Configure sources, targets, schedules, and table lists in SQLPro | Own the copy activities, watermark logic, schema drift handling, and MERGE/COPY scripts |
| Source pressure | Change Tracking records only that a row changed - less log and storage pressure than full CDC-style approaches | Depends on design; full-reload and CDC approaches are typically heavier |
| Built-in data validation | Scheduled row-count and checksum comparisons between source and target | Requires a separate validation pipeline |
| Resyncs and delta isolation | Delta and resync queues are separate - a full table reload does not block ongoing incremental sync | Full-reload and incremental jobs share the same pipeline resources |
| Load path into Fabric DW | Initial load: Parquet → Blob → COPY INTO. Delta: temp table in Fabric followed by MERGE - no staging hop |
Flexible; you choose and build the load pattern |
| Operational visibility | Queue monitoring, sync status, schedules, and reconciliation are built-in product features | Must be built into each pipeline (alerts, logging, dashboards) |
| Source types | SQL Server, Azure SQL, and Azure SQL Managed Instance only | Many connectors (files, APIs, other databases, Lakehouse, and more) |
| Table requirements | Base tables with a primary key only | Any table, view, or arbitrary SQL query |
| Data transformations | None - 1:1 column replication, with an optional column subset per table | Full ETL: joins, filters, expressions, lookups, and column remapping |
| Delete handling | Hard deletes are applied to the target via MERGE |
Configurable - hard delete, soft delete, or custom logic |
When to use SQLPro Sync
SQLPro Sync is the right choice when:
- You want SQL Server tables continuously replicated into Fabric with low engineering effort.
- Your tables have primary keys and you need inserts, updates, and deletes reflected in the target.
- You want scheduled row-count and checksum validation without building a separate reconciliation pipeline.
- Keeping the source SQL Server lightly loaded matters.
Tip
If you are loading many tables from one or more SQL Server databases into a Fabric Data Warehouse, SQLPro Sync will typically take significantly less time to configure and maintain than an equivalent set of Fabric pipelines.
When to use Fabric Pipelines
Fabric Pipelines are the right choice when:
- Your source is not SQL Server (files, APIs, other databases, Lakehouse, etc.).
- The tables you need to load do not have a primary key.
- You need to transform, join, or filter data on the way into Fabric.
- You need to sync views or the results of arbitrary SQL queries.
- You need soft-delete behaviour or custom control over how inserts, updates, and deletes are applied in Fabric.