Back to Blog

Fabric Data Factory Connector Capability Comparison - Pipelines vs Dataflows vs Copy Job

October 18, 2026•7 min read•Michael Ridland

Here's a conversation I've had more than once this year. A client's data engineer builds a proof of concept in Dataflow Gen2, pulling from an on-premises Oracle database through the gateway. It works nicely. The project gets approved. Then they try to move the heavy loads into a pipeline Copy activity for performance, and discover the connector they need either doesn't support the gateway the same way, or doesn't support the write-back they assumed, or isn't available in that experience at all.

The fix isn't hard once you know about it. But it can cost a sprint, and it's avoidable. Microsoft publishes a connector capability comparison for Fabric Data Factory that lays out which connectors work in which experiences and with which capabilities. It's one of the least glamorous pages in the Fabric docs and one of the most useful. I'd make it required reading before anyone writes a Fabric data architecture document.

Why connectors behave differently in different places

The key thing to understand is that "Fabric Data Factory" is not one engine. It's several experiences sitting under one brand:

  • Dataflow Gen2 is built on Power Query. Its connectors come from the Power Query connector family, the same lineage as Power BI Desktop and Excel.
  • Pipelines, specifically the Copy activity and Lookup activity, come from the Azure Data Factory lineage. Their connectors are a different implementation.
  • Copy job is the newer, simpler data movement experience, which shares a lot with the pipeline connector stack but has its own support list and its own incremental copy behaviour.
  • Mirroring is separate again, with its own short list of supported sources.

So when you see "Snowflake connector" in Fabric, there may actually be two or three different pieces of code behind that name depending on where you use it. They get built and shipped by different teams at different times. That's why the parity page exists.

What the comparison actually tells you

The connector parity documentation is essentially a big matrix. For each connector you can see whether it's supported in Dataflow Gen2, in pipelines, and in Copy job, and then for the relevant experiences whether it supports things like:

  • Use as a source versus a destination
  • On-premises data gateway connectivity
  • Virtual network data gateway connectivity
  • Authentication types available

The source versus destination distinction catches people out more than anything else. Plenty of connectors are read-only in one experience and read-write in another. Dataflow Gen2 has a fairly short list of output destinations (lakehouse, warehouse, Azure SQL, KQL database and a handful of others), while pipelines can write to a much wider set of targets. If your design involves writing data back to an operational system, check this first.

Gateway support is the second big one. A lot of Australian organisations still have core systems on-premises or in private networks, especially in government, health, mining and financial services. Whether a connector works through the on-premises data gateway or a VNet gateway in a given experience can decide your whole architecture.

How we use it on projects

On Fabric projects we now do a short connector check in the first week, before anyone gets attached to a design. It's not complicated:

  1. List every source and every destination system, including the authentication method each one will use in production (not the one that's convenient for the POC).
  2. Note where each system lives: public cloud, private network behind a VNet, or on-premises behind a firewall.
  3. Look each one up in the parity matrix and mark which Fabric experiences can handle it with the required connectivity and auth.
  4. Flag any gaps and decide the workaround now.

That last step is where the value is. Typical workarounds we land on:

  • Use Dataflow Gen2 for a source that's only supported there, land it in a lakehouse, then use pipelines or notebooks for everything downstream.
  • Use a pipeline Copy activity to stage data in a lakehouse when Dataflow Gen2 can't write to the destination you need.
  • Use a notebook with a Python or Spark library for the odd source that isn't well covered by any connector. This is more code to maintain, but sometimes it's the honest answer.
  • Push back on authentication choices. Sometimes the connector supports service principal in one experience and only basic auth in another, and the security team won't allow basic auth. Better to know that in week one.

I had a client in logistics where the parity check showed that their main source system's connector supported the on-premises gateway in Dataflow Gen2 but the pipeline route they'd planned needed a different connectivity setup. We changed the design to use Dataflow Gen2 for extraction into a lakehouse, with pipelines handling orchestration. That cost us about an hour of design time. Finding it in month two would have cost a lot more.

Honest opinions on where things stand

A few things I'd tell a colleague over coffee.

The gap is closing, but it's not closed. Over the past year Microsoft has added a lot of connectors to pipelines and Copy job, and gateway support has been extended to more experiences. It's much better than it was when Fabric went GA. But "it works in Power BI Desktop" still doesn't mean "it works in a Fabric pipeline", and people keep assuming it does.

Preview status matters. Some connector capabilities are marked as preview. I'm comfortable using preview features in development and for non-critical loads, but I'm cautious putting a preview connector at the centre of a production finance feed. Preview things change, and support is lighter.

The docs lag reality, in both directions. Occasionally something works that the matrix says doesn't, or the other way round. Use the page as your starting point, then test with your actual source, network and credentials before you commit. Fifteen minutes of testing in a dev workspace settles most arguments.

Copy job is underrated. For straightforward bulk and incremental loads from a supported source into a lakehouse or warehouse, Copy job is often the simplest option and it's worth checking whether your source is on its list before you build a full pipeline. Less to maintain is a real benefit.

Dataflow Gen2 has the broadest source coverage but costs more capacity. Because it's Power Query, it can reach a huge number of sources. It can also chew through capacity units on large volumes. We often use it for the long tail of smaller sources and use pipelines or Copy job for the big ones.

If you're migrating from Azure Data Factory

A lot of our Fabric work is migration from Azure Data Factory or Synapse pipelines. If that's you, the connector comparison is doubly important, because not every ADF connector has a Fabric equivalent yet, and some that do have different capability coverage. Run your existing linked services through the matrix before you commit to a migration timeline. Where there are gaps, it's perfectly reasonable to keep a few ADF pipelines running alongside Fabric for a while. Hybrid isn't a failure, it's just sensible sequencing.

Getting help

If you're planning a Fabric data platform and want a second set of eyes on your source systems and connectivity, our Microsoft Data Factory consultants do exactly this kind of design review. For the wider platform, including lakehouse design, capacity sizing and governance, talk to our Microsoft Fabric consultants. And if you're hoping to put AI agents over that data eventually, it's worth reading about how we approach AI integration, because clean, reliable ingestion is the bit that makes everything after it possible.

My short version: before you draw the architecture diagram, open the connector parity page and check every source and destination against it. It's the cheapest risk reduction you'll do on the whole project.