Fabric SharePoint list mirroring, or a SQL replica?

23 October 2026

Tags: Relational databasesWarehouses and lakesDesktopCommand line

The message usually comes from someone senior who has just watched a Fabric demo. “Can we not just mirror the SharePoint list into Fabric? It’s free.” Your team runs SQL Server, or Postgres, and Power BI on Pro licences. Nobody has bought a Fabric capacity, and the list in question is the one behind the monthly report: a few thousand jobs, a Client lookup, an Engineer person column and a refresh that fails twice a week.

Part of what you were told is true. Microsoft does not charge for the compute that mirrors a SharePoint list into OneLake. What the demo left out is the capacity that mirroring runs on, the preview label, and the questions Learn does not answer yet. This post sets those out with the facts as they stood on 23 October 2026, and then compares a mirror with a SQL replica in the database your team already looks after.

What does Fabric SharePoint list mirroring give you?

Microsoft’s page on mirroring a SharePoint list in Fabric describes a continuous copy of the list into OneLake, stored as Delta tables. In a workspace you choose New, then Mirrored SharePoint Online List, give it the site and a sign-in, and Fabric creates a mirrored database item. Each mirrored database gets a SQL analytics endpoint, which Microsoft calls a read-only copy: you can write T-SQL views, functions and stored procedures over the tables, and query them from SQL Server Management Studio or Power BI, but you cannot change the data through it.

The pricing on that page is generous. There is no charge for the compute that replicates the list, and none for OneLake storage up to a limit tied to the capacity size. You pay for the capacity compute your queries use, from SQL, Power BI or Spark. The mirroring overview puts the free storage at one terabyte per capacity unit, far more than any SharePoint list needs.

If your organisation already runs a Fabric capacity for other work, that makes mirroring cheap to try. Our comparison of SPSync with Fabric’s own tools covers mirroring, Dataflow Gen2 and Copy jobs side by side for that case, and the Fabric destination page covers the routes into a Lakehouse. This post is about the other case, where there is no capacity yet.

What a Fabric capacity costs a team that has none

The same overview is plain about the dependency: a running Fabric capacity is required for mirroring, and a paused or deleted capacity affects mirroring and replicates nothing. The set-up tutorial asks for a workspace on a Trial or Premium Fabric capacity. A Power BI Pro or Premium Per User licence does not count, because, as Microsoft’s licensing page puts it, Premium Per User does not provision a Fabric capacity.

So the free replication sits on top of a capacity you pay for. The smallest is F2, with two capacity units. A pay-as-you-go capacity is billed for every hour it runs, and a mirror needs it running around the clock. A one-year or three-year reservation costs less than pay-as-you-go, in exchange for the commitment. Prices vary by region and term and change over time, so read Microsoft’s Fabric pricing page for your own region on the day you decide.

Three details matter as much as the price itself:

• The usual way to cut a capacity bill is to pause it out of hours, and Azure bills F capacities by the second with a one-minute minimum. A mirror cannot use that saving: while the capacity is paused nothing is replicated, and the overview says you pay for OneLake storage while it is paused.
• On an F SKU smaller than F64, the licensing page says every user viewing Power BI content still needs a Pro, Premium Per User or trial licence. A small capacity adds to your Pro licences and does not replace them.
• F2 is a small capacity shared by everything in it. The mirroring itself does not draw on it, but every query, report and notebook over the mirror does.

None of that makes Fabric expensive for a team that will use it for more than one list. It does mean that for a team without one, the comparison starts with a monthly capacity bill on the Fabric side.

Can you mirror a SharePoint list to Fabric without a capacity?

Not for long. The Fabric trial gives a capacity for 60 days, configured as F4 or F64, and that is enough to set up a mirror and see what your list looks like in OneLake. It is the right way to answer the questions in the next section before anyone commits.

Do not build the monthly report on it. Microsoft limits the number of trial capacities a tenant can create, and when a trial ends the non-Power BI items in its workspaces, a mirrored database among them, become unusable. Learn says they may be deleted after seven days unless you assign the workspace to a paid F or P capacity. A trial is a test run, and the decision about paying for a capacity is still waiting at the end of it.

What Learn does not say about a mirrored SharePoint list

The second half of the decision is about the data. The SharePoint list mirroring page is short, and on 23 October 2026 it says nothing about:

• how a lookup column arrives, whether as an id, a display value or both;
• how a person column or a multi-choice column is stored;
• what happens to a row when the item is deleted in SharePoint;
• what happens to existing tables when someone adds or retypes a column in the list.

Other mirroring sources, such as Azure SQL Database, have a limitations page on Learn. SharePoint List does not, and the URL where one would sit returns a 404. The overview describes replication as near real time, with the delay depending on the volume and frequency of changes, and gives no figure for SharePoint.

None of this means the mirror handles those cases badly. It means you find out on your own list. If you run a trial, delete a test item, add a column and look at how the Client lookup and the Engineer column arrive before you plan any reports on them.

A SQL replica of the same SharePoint list

The alternative keeps the copy in a database you already run. SPSync replicates the list one way, out of SharePoint, into SQL Server, Azure SQL or PostgreSQL. SharePoint stays the system of record and SPSync never writes back to it. The first run reads every item; after that it reads only what changed through Microsoft Graph delta queries, every few minutes by default, with a reconcile behind it, weekly by default.

The shape of the replica is documented, which is the part a preview cannot offer yet. The Client lookup becomes client_id and client_value, the Engineer column becomes engineer_user_id, which joins to one shared sp_users table, and a multi-choice column gets a child table with a row per value. A deleted item stays in the table with sp_deleted_at set, so last month’s total can still be explained after someone tidies the list. New columns appear in the table without anyone editing a query. The schema reference has every column type.

Power BI reaches the replica through connectors your team probably uses already. Both the SQL Server connector and the PostgreSQL connector support Import and DirectQuery, and a server that is not on the internet is reached through an on-premises data gateway. That matters for freshness on Pro licences. Microsoft’s refresh page limits an Import model on shared capacity to eight scheduled refreshes a day, against 48 on a Fabric capacity, and says only Import models need a refresh at all. A DirectQuery report over the replica reads the table when someone opens it, so it shows the data as of the last SPSync run with no refresh schedule to manage.

Mirror and replica side by side

SPSync has no public price list. It is licensed per installation and per target family on annual terms, and quoted after a call, so the fair comparison is a quote set against Microsoft’s price for your region. A trial on your own list, which we set up on the same call, answers the shape questions in an afternoon.

When is Fabric mirroring the better choice?

Mirroring wins when the capacity is not really an extra cost. If your organisation is moving its reporting into Fabric anyway, you will pay for a capacity whatever you decide about this list, and mirroring adds the list for no replication charge. The same is true when the list is one of several sources you want in OneLake beside other mirrored databases, or when the analysts asking for it already work in Fabric notebooks and Direct Lake models.

It is also a reasonable choice when the list is plain. A list of text, number and date columns with no lookups, where deletes do not affect any total, avoids most of the questions in the section above.

The SQL replica fits a team whose reports, applications and skills live in SQL Server or Postgres, with no capacity on the budget. It also fits when lookups and deletes need to be right on the first day, when an application or a stored procedure needs the same rows as the report, or when the security team will grant read access to named sites and no more. SPSync can run app-only with Sites.Selected.

Building the SQL replica, step by step

For a SQL Server or Postgres team starting from the failing report, the work looks like this:

1. Note which lists and columns the Power BI report reads today, and which lookups it joins.
2. Create a database, or a schema in an existing one, and a login SPSync can write with.
3. In the desktop app or the command-line tool, connect to the SharePoint site and pick the lists. The schema preview shows the tables and columns before anything runs.
4. Choose SQL Server, Azure SQL or PostgreSQL as the destination and run the first full copy.
5. Set the schedule. Every few minutes is the default. The reconcile, weekly by default, is a QA check that compares the replica with SharePoint, and you can also run it after an outage on your side.
6. In Power BI Desktop, connect with the SQL Server or PostgreSQL connector, choose DirectQuery or Import, and add a gateway if the server is on your own network.
7. Filter out rows where sp_deleted_at is set, rebuild the joins on the _id columns and publish. Retire the old SharePoint list query once the totals match.

The Power BI use case and the post on why Power BI refreshes on SharePoint lists slow down go further into the report side.

If you take on Fabric later

Choosing a SQL replica now does not shut the door on Fabric. SQL Server and Azure SQL Database are both sources the mirroring overview lists, so a team that buys a capacity next year can mirror the replica, lookups and deletes already modelled, into OneLake. We have not tested Fabric mirroring against SPSync’s tables ourselves, so check the source’s limitations page against your schema first. The Fabric destination page covers that route and its Azure SQL tier limits.

There is a file route as well. SPSync’s Azure Data Lake Storage Gen2 destination writes Parquet, and its Delta Lake destination writes Delta tables, to a container you own. A OneLake shortcut lets a Lakehouse read them without a copy, which the post on Parquet, Delta Lake and Iceberg walks through. A native Fabric destination in SPSync is on the roadmap and has not shipped. If that is what you would wait for, tell us how many lists you have and how current the data needs to be.

Whichever route you take, test on the list that causes the trouble, the one with the most lookups and the most deletes, before anyone rebuilds a report on it.