SharePoint list to Microsoft Fabric Lakehouse and OneLake

Last updated 23 October 2026

Status: Coming soon · product: SPSync for Warehouses & Lakes . We prioritise destinations by demand. Book a call to tell us you need it.

SPSync copies SharePoint lists one way, out of SharePoint, which stays the system of record, and it does not write to Microsoft Fabric yet. A native Fabric destination is on the roadmap. What ships today is Parquet and Delta Lake on Azure Data Lake Storage Gen2, which a Fabric Lakehouse reads through a OneLake shortcut. Microsoft now mirrors SharePoint lists into Fabric itself, so this page compares the three routes and says when each one fits.

Which route gets a SharePoint list into a Fabric Lakehouse?

Pick mirroring if your reports and agents already live in Fabric and a preview is acceptable. Pick an SPSync route if the copy has to serve readers outside Fabric, or you want to control the schema, the schedule and the storage account it sits in.

Fabric mirroring for SharePoint lists

Microsoft’s Mirroring SharePoint List in Microsoft Fabric continuously replicates a list into OneLake and gives the mirrored database an autogenerated, read-only SQL analytics endpoint. The same page says Microsoft does not charge for the compute that replicates the data, or for OneLake storage up to your capacity size; you pay for the capacity compute used when you query it. The mirroring overview lists SharePoint List as a preview source, and the set-up tutorial asks for a workspace on a Trial or Premium Fabric capacity.

The Learn pages do not say how lookup and person columns arrive, or what a deleted item looks like in the mirror. Mirror one list and check both before you build reports on it. The comparison of SPSync with Fabric’s own tools covers Dataflow Gen2 and Copy jobs as well. If your team has no Fabric capacity yet, the post on choosing between a mirror and a SQL replica sets out what running a capacity involves and what a replica in SQL Server or Postgres gives you.

SharePoint list to OneLake with SPSync today

Two shipped SPSync destinations write to an ADLS Gen2 container you own, and a OneLake shortcut points a Lakehouse at that container without copying the files.

1. Replicate the lists with the Azure Data Lake Storage Gen2 destination. Each table gets a folder holding current.parquet, replaced every run, and one history file per run.
2. In a Fabric Lakehouse, create a shortcut to the container in the Files folder.
3. Read current.parquet from a notebook, or load it into a Lakehouse table with a notebook or pipeline on your own schedule.

Microsoft’s shortcut page explains the limit of that route: the Files folder does no table discovery, so Parquet there stays as files. A shortcut in the Tables folder whose target is in Delta format is recognised as a table. SPSync’s Delta Lake destination writes Delta tables to ADLS Gen2 through an abfss:// URL, merged on the SharePoint item ID each run, so a Tables shortcut to one of its table folders should appear in the Lakehouse as a table with no load step. We have not yet tested that pairing on a live Fabric workspace, so try it on one table before you depend on it.

Either way the shape is SPSync’s own. A lookup becomes {col}_id and {col}_value, a person column points at one shared sp_users table, and a multi-choice column gets a child table. Deleted items stay in the data with sp_deleted_at set, so filter on that column in reports. Managed metadata columns are skipped and reported on each run. The schema reference has the full column mapping.

A SQL replica in Azure SQL, read from Fabric

SPSync’s Azure SQL destination keeps each list as a table in Azure SQL Database and updates it from SharePoint’s delta query on every run. Power BI reads that database directly. To bring it into OneLake as well, Azure SQL Database is a source that Fabric mirroring supports, again with free replication compute. That page says databases in the Free, Basic or Standard DTU tiers with fewer than 100 DTUs are not supported. We have not run Fabric mirroring against SPSync’s tables, so read the table and column limitations against your schema first.

This route fits when an application or a SQL Server reporting estate needs the same copy. The database holds the data and Fabric becomes one of several readers.

Can a Fabric data agent read a SharePoint list?

It reads tables, so the list has to reach a table first. Microsoft’s data agent page names lakehouses, warehouses, Power BI semantic models, KQL databases, mirrored databases and ontologies as sources, up to five per agent. For a Lakehouse, the agent uses the tables you select and does not read standalone files unless they are loaded or exposed as tables. Its answers are capped at 25 rows and 25 columns, so it summarises data and does not hand back a whole list.

That gives a Lakehouse-first rule for SharePoint data. A mirrored list, SPSync Delta tables behind a Tables shortcut, SPSync Parquet loaded into a Lakehouse table, or a mirrored Azure SQL copy can each be selected as a source, though the Delta shortcut is the pairing we have not yet tested on a live workspace. Parquet left behind a Files shortcut cannot. Because SPSync turns lookups into key and value columns, the SQL the agent writes can join one list to another on the key.

What a native Fabric destination would decide

The engine would not change. Delta sync, soft deletes, schema evolution and the column mapping above belong to SPSync’s engine, so a Fabric destination inherits them. The open questions are Fabric’s own: whether the target is a Lakehouse table, a Warehouse table or a choice of both, how rows are written to OneLake, and how SPSync signs in to a workspace. None of that has been decided, and this page will not describe it until it is built.

Register interest in a Fabric destination

Tell us what you would sync: Lakehouse or Warehouse, how many lists, roughly how many rows, and how current the data needs to be. Get in touch with that and we will tell you where Fabric sits on the roadmap, and let you know when it ships. When it does, it will appear in the desktop app, SPSync in your Azure and the command-line tool together, as every destination does.

# This destination has no --destination-kind in the command line today.
# In the meantime, run this from a shipped destination (Postgres or SQL Server)
# and repoint --connection-string-env at your database.

# YAML for this destination's kind ships with its --destination-kind support.

# every night at 02:00
0 2 * * * cd /opt/spsync && SPSYNC_DB_CONNECTION="$(cat /etc/spsync/db.env)" uv run spsync run replication.yaml >> /var/log/spsync/run.log 2>&1

# .github/workflows/spsync-run.yml
name: SPSync
on:
  schedule:
    - cron: "0 2 * * *"
  workflow_dispatch: {}
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync
      - run: uv run spsync run replication.yaml
        env:
          SPSYNC_DB_CONNECTION: ${{ secrets.SPSYNC_DB_CONNECTION }}
          SPSYNC_LICENCE_KEY: ${{ secrets.SPSYNC_LICENCE_KEY }}

# azure-pipelines.yml
schedules:
  - cron: "0 2 * * *"
    branches: { include: [main] }
    always: true
steps:
  - script: uv sync
  - script: uv run spsync run replication.yaml
    env:
      SPSYNC_DB_CONNECTION: $(SPSYNC_DB_CONNECTION)
      SPSYNC_LICENCE_KEY: $(SPSYNC_LICENCE_KEY)

# Windows Task Scheduler action (see /docs/cli/automation/)
$env:SPSYNC_DB_CONNECTION = (Get-Content C:\spsync\db.env)
uv run spsync run C:\spsync\replication.yaml
schtasks /Create /SC DAILY /ST 02:00 /TN "SPSync" /TR "powershell -File C:\spsync\run.ps1"

# ~/Library/LaunchAgents/io.spsync.run.plist, then: launchctl load ~/Library/LaunchAgents/io.spsync.run.plist