SPSync vs Fabric mirroring, Dataflow Gen2 and Copy jobs for SharePoint lists

Choose SPSync when the list must reach a database outside OneLake or you need lookups as keys and deleted items kept; choose Fabric mirroring or Dataflow Gen2 when every report already lives in Fabric.

Documentation reviewed 23 October 2026

Where Fabric fits

• Mirroring (in preview) replicates a SharePoint list into OneLake continuously, and Microsoft charges nothing for the replication compute
• a mirrored list gets a read-only SQL analytics endpoint that Power BI and SQL tools can query
• Dataflow Gen2, a pipeline Copy activity and Copy job can all read a SharePoint list as a source
• built into Power BI and Fabric, with no extra product to buy if you already run a capacity

Where it breaks

• Mirroring for SharePoint lists is in preview, and Learn has no limitations page for it
• every route needs a running Fabric capacity, which is a commitment if you do not already run one; a paused capacity stops mirroring
• mirroring writes to OneLake only
• lookups and multi-choice columns are not documented as being normalised into relational tables, on any of the routes
• Copy job reads a SharePoint list as a full load only, so every run copies the whole list again
• deleted items are not documented as tracked, so an item removed in SharePoint leaves no record in the copy
• Dataflow Gen2 and Copy job runs consume Fabric capacity, and the connector is bound by SharePoint's list view and lookup thresholds, including a 12-join limit

Feature by feature

Your reports already run in Fabric and the data behind one of them sits in a SharePoint list. You want it in OneLake without hand-building a pipeline, and Fabric now offers more than one way to do it. This page sets out what Microsoft documents for each route, where each one stops, and when SPSync is the better choice. For how mirroring differs from sync, copy and replication in Microsoft’s own usage, see what each word means for a SharePoint list.

How does Fabric mirroring work for a SharePoint list?

Fabric mirroring can replicate a SharePoint list into OneLake. In a workspace you choose New, then Mirrored SharePoint Online List, and give it the site URL and a sign-in. Microsoft’s SharePoint list mirroring page says Fabric then replicates the list continuously as Delta tables. Each mirrored database gets a SQL analytics endpoint, which is a read-only copy: you can write T-SQL views and queries against it but cannot change the data. Document library data reaches OneLake through shortcuts, without a copy.

What to know before relying on it, checked on Microsoft Learn on 2026-10-22:

• The mirroring overview lists SharePoint List as a preview source.
• Microsoft charges nothing for the compute that replicates the list, and mirroring storage in OneLake is free up to a limit tied to your capacity size. Queries from SQL, Power BI or Spark are billed against your capacity as usual.
• It needs a running Fabric capacity. The overview says a paused or deleted capacity stops replication, and the setup tutorial asks for a Trial or Premium capacity.
• The copy goes to OneLake and nowhere else.

What Learn leaves out matters as much. SharePoint list mirroring has no limitations page, though sources such as Azure SQL Database have one, and the SharePoint page does not describe how lookup columns, multi-value columns or deleted items arrive in the Delta tables. The overview calls mirroring near real time and says the delay depends on the volume and frequency of changes, with no figure for SharePoint. Check how your own list’s lookups and deletes come through before building reports on a mirror.

SharePoint list to a Fabric Lakehouse with Dataflow Gen2 or a Copy job

Before mirroring, Fabric had two ways in, and both still work. Microsoft’s connector page lists a SharePoint list as a source for Dataflow Gen2, for the Copy and Lookup activities in a pipeline, and for Copy job.

A Dataflow Gen2 follows the steps in Microsoft’s connection guide:

1. In the workspace, choose New and then Dataflow Gen2.
2. Choose Get data and pick SharePoint Online list.
3. Enter the site URL, a gateway if you need one, and the authentication kind.
4. In the Navigator, pick the list and choose Transform data to shape it in Power Query.
5. Set a data destination, such as a Lakehouse table, and a refresh schedule.

Copy job is simpler still: pick a source, pick a destination, and it runs. For a SharePoint list, though, Copy job is full load only, so each run reads the whole list again. When the list is modest and every downstream report is already in Fabric, staying on one platform means one less tool to run. That is often the right call.

How often can I refresh SharePoint data in Fabric?

It depends on the route. Mirroring runs continuously once it is set up, with the near-real-time caveat above. A Dataflow Gen2 refreshes on demand or on a schedule of up to 48 times a day, according to Microsoft’s refresh page (checked 2026-10-22). A Copy job runs when you schedule it and copies the whole list each time.

Dataflow and Copy job runs consume Fabric capacity, so their cost depends on your capacity and how often you refresh. A schedule short enough for an operational dashboard runs often, and those runs share the capacity with everything else on it. Mirroring moves that cost off the replication and onto the queries. Without a Fabric capacity already in place, any of these routes starts with taking one on to copy a list.

SPSync reads changes every few minutes by default and runs a reconcile weekly by default. You set both in the desktop app, the command line or a CI job.

The shape of the copy

Microsoft describes the output in terms of SharePoint’s own columns. Lookup and multi-choice columns are not documented as turning into relational keys or child tables on any of these routes, so expect to model them downstream. A full load gives you the list as it stands on the day, with nothing to say which items were deleted since the last run or when. If finance asks why last month’s total moved, you will need your own snapshot to answer.

SPSync writes a normalised schema to the database you choose. After the first full copy it reads only the changes from SharePoint. Lookups become key columns you can join on, and multi-value columns become child tables. Deleted items are kept as soft deletes by default, and new SharePoint columns appear without anyone editing a query.

When to use SPSync instead of a Fabric mirror of a SharePoint list

Mirroring is the closest thing Microsoft offers to SPSync, and where all your reporting lives in Fabric it may be enough. SPSync is the better fit when one of these applies:

• The copy has to live outside OneLake: Azure SQL, SQL Server, PostgreSQL, MySQL, BigQuery, Databricks or another of the shipped destinations, on your own servers or in AWS or Google Cloud.
• Lookups should arrive as key columns you can join on, and multi-value columns as child tables.
• Deleted items have to be kept. SPSync soft-deletes by default, so a removed item stays as a row with its deletion time and last month’s total can still be explained.
• You choose the schedule and run it from the desktop app, a server or CI.
• Your security team will grant read-only access to named sites and no more. SPSync can run app-only with Sites.Selected, and it never writes to SharePoint.
• Analysts want tables in their own database, with views and dbt models built over them.
• You do not run a Fabric capacity and would prefer not to take one on for a list.

For a team in that last position, our post on Fabric SharePoint list mirroring or a SQL replica weighs the cost of running a capacity against a replica in the database you already run.

If you still want the data in Fabric, the Fabric page describes the route that works today: replicate to Azure Data Lake Storage Gen2 and point a OneLake shortcut at the container. A native Fabric destination is on the roadmap and has not shipped.

Moving off a dataflow or a mirror

1. List the lists and columns the dataflow, pipeline, Copy job or mirror reads.
2. Connect SPSync to the same SharePoint site and pick those lists.
3. Choose the destination, such as Azure SQL, SQL Server or PostgreSQL, and set the sync schedule.
4. Compare the new tables with the Fabric copy, paying most attention to lookup and multi-value columns.
5. Repoint the Power BI reports and retire the dataflow, Copy job or mirror.

You can run SPSync from the desktop app on macOS or Windows, or from the command line in CI or on a server. SPSync in your Azure, a managed application for your own subscription, is deployed with you on a call while the Marketplace listing is prepared. Once deployed it is always on.

SPSync as a Fabric alternative for SharePoint lists

SPSync reads only the changes after the first load, keeps deleted items with a timestamp and turns lookups into key columns. Power BI reads the replica from Azure SQL, SQL Server or PostgreSQL, on your own servers or in any cloud, and SPSync's runs draw nothing from a Fabric capacity.

Other alternatives

• Azure Data Factory: the same SharePoint list connector outside Fabric, with the incremental logic built by you.
• Power Query: the engine inside Dataflow Gen2, used straight from Power BI Desktop for smaller lists.
• Fivetran: a managed Microsoft Lists connector that loads a warehouse on a schedule and bills by Monthly Active Rows.
• Coupler.io: refreshes Microsoft Lists into Power BI, BigQuery or PostgreSQL on a schedule, with no Fabric capacity involved.