Microsoft Fabric vs Azure Synapse Analytics
This comparison is different from the others — Fabric and Synapse share an engine lineage, so the question isn't really "which platform" so much as "what carries over directly, and what needs a genuine rebuild."
At a glance
| Dimension | Synapse | Fabric |
|---|---|---|
| Pipelines engine | Synapse Pipelines (Azure Data Factory) | Fabric Data Pipelines — the same engine again |
| SQL compute | Dedicated SQL pools (hash/round-robin/replicate distribution) + serverless SQL pools | Fabric Warehouse over Delta — no distribution model to configure |
| Spark | Spark pools, mssparkutils | Spark in a notebook/Environment, notebookutils (successor, mostly a rename) |
| Storage | ADLS Gen2, queried via external tables / serverless SQL | OneLake (Delta Lake) — every engine reads the same table natively |
| Operational DB replication | Synapse Link (SQL, Dataverse, Cosmos DB) | Database mirroring — same concept, built by the same team |
| Security model | Workspace RBAC + SQL-level roles | Workspace roles + OneLake security (RLS/CLS/TLS enforced at the data layer) |
| Billing unit | Per-pool DWU/vCore + serverless pay-per-TB-scanned | Capacity Units — one shared, smoothed pool across every workload |
What carries over almost unchanged
- Pipelines. Synapse Pipelines are Azure Data Factory. Fabric Data Pipelines are the same engine again. Most activities — Copy, Lookup, ForEach, Execute Pipeline, web/webhook calls — translate directly from exported JSON; the real work is re-pointing linked services to Connections.
- Spark notebooks. The %%pyspark and %%spark cell magics carry over as-is. mssparkutils becomes notebookutils, mostly a rename.
- Synapse Link sources. SQL, Dataverse, and Cosmos DB replication maps close to directly onto database mirroring.
What needs a genuine rebuild
- SQL pool distribution. A dedicated pool's HASH, ROUND_ROBIN, and REPLICATE options have no Fabric equivalent — there's no "how is this table physically distributed" concept to configure. A hash-distributed fact table becomes a normal Delta table Z-ordered on the former hash key; a replicated dimension becomes just a small table, since size alone triggers broadcast behavior.
- Security and RBAC. Synapse's workspace RBAC and SQL-level roles don't have an export/import path into OneLake security. Design the role set fresh from current requirements rather than trying to port it — most access models accumulate years of scope creep anyway, so this is a forcing function worth taking.
- Serverless SQL pool views and PolyBase external tables. Views over external files with schema encoded inline, and PolyBase-style external tables, don't repoint cleanly — they get rebuilt against the Lakehouse SQL endpoint or as a shortcut, since column mapping and type inference behave differently.
Migrating from Synapse to Fabric
If you've decided to move, the step-by-step order — pipelines first, Synapse Link sources in parallel, Spark notebooks next, dedicated SQL pool tables last — plus the full mapping table and the PolyBase/serverless-view gotchas, is in the migration playbook.
Read the migration playbookFAQ
Is Fabric just Synapse renamed?
No — it's a real architectural shift, not a rebrand. Synapse Pipelines and the Data Factory engine carry over almost unchanged, but Synapse's dedicated SQL pool distribution model (hash/round-robin/replicate) has no equivalent in Fabric at all. A Fabric Warehouse sits on Delta tables in OneLake and relies on file layout — Z-order, liquid clustering, file size — to do what distribution used to do. That's a different execution model to design for, not a setting to toggle.
Is Microsoft retiring Synapse?
Microsoft's public direction has been that Fabric is where Synapse capability is headed, but exact timelines and what happens to existing Synapse workspaces are the kind of thing that shifts — check current guidance directly rather than trusting a specific date on this page. What's solid regardless of timeline: anything new you'd build in Synapse today has a direct Fabric equivalent, so building there doesn't buy you anything incremental.
What's the single hardest part of migrating?
Dedicated SQL pool tables that leaned heavily on distribution tuning for a handful of huge fact tables. Translating a hash-distributed fact table into a Z-ordered Delta table or a replicated dimension into a small broadcast-friendly table is design work with real judgment calls, not a mechanical export — budget real time for it specifically, separate from the pipeline and Spark-notebook migration, which are comparatively mechanical.
Is Fabric cheaper than Synapse?
It depends on the shape of what you're running, and a flat answer either way is a guess. Synapse bills dedicated pools by DWU/vCore and serverless by TB scanned; Fabric Capacity Units pool every workload — Warehouse, Spark, pipelines — against one smoothed budget. Teams running several underutilized dedicated pools often find consolidating onto one Fabric capacity cheaper; teams with one enormous, consistently busy pool may not. Model your actual workload in the CU cost calculator rather than assuming.
Does Synapse Link map directly to Fabric mirroring?
About as directly as any migration gets. Fabric's database mirroring is the same idea — continuous, low-latency replication into read-only Delta tables — built by the same team with the lessons from Synapse Link folded in. Stand up the mirror against the same source, validate row counts match the existing Synapse Link tables, then cut the old link.