SharePoint to SQL Server tools compared
The finance team wants the Projects list joined to the ledger in SQL Server, and the copy you have today is a package, a flow or a script that somebody built in a hurry. It misses deleted items, a lookup column arrives as a bare number, and it fails on the nights the list is busy. You search for a SharePoint to SQL Server tool and find a dozen vendor pages, each one sure that it is the answer.
This page puts the tools that write SharePoint list data into SQL Server or Azure SQL side by side, and asks each of them the same nine questions. Every row restates a page on this site that covers the tool in full, with its sources and the date we read them, and links to it. A list you open in Microsoft Lists is a SharePoint list underneath, so all of it applies there too. If your destination is something other than SQL Server, SharePoint list to a database is the wider view, covering every route and every kind of destination.
Which SharePoint SQL Server integration tools are there?
They fall into four groups. Microsoft's own routes are Power Automate and Logic Apps, Azure Data Factory, and the Fabric data tools. Integration Services is the route for teams who already run SSIS, usually with a third-party SharePoint component from a vendor such as KingswaySoft or ZappySys. Vendor products that list SQL Server as a destination include CData Sync, Skyvia, Layer2 Cloud Connector, Fivetran, Airbyte and Peliqan. Then there are the scripts you write yourself with PnP PowerShell or Python, and SPSync, which does only this job.
Fabric mirroring is in the table because people ask about it, but it writes to OneLake, not to SQL Server. Coupler.io also comes up in searches, but its Microsoft Lists connector loads spreadsheets, BI tools and warehouses such as BigQuery, Snowflake and PostgreSQL, and lists no SQL Server or Azure SQL, so it is not in the table. SPSync vs Coupler.io covers it.
The SQL Server tools side by side
Each cell describes the tool as it ships, before anyone adds code around it. Any of these gaps can be closed by a script or a pipeline step, if you are willing to own the code that closes it. "Not covered by our comparison" means our page on that product does not say how it reads a list past the 5,000-item list view threshold, so ask the vendor.
| Tool | Lists or files | Direction | Lookups normalised | How often | Past 5,000 items | Deletes | Where it runs | Pricing model | Self-hosted |
|---|---|---|---|---|---|---|---|---|---|
| SPSync | Lists and document library metadata; file contents stay in SharePoint | One way, SharePoint to SQL Server or Azure SQL | Key columns you can join on, with multi-value columns as child tables | Every five minutes by default, plus a reconcile, weekly by default | Graph delta reads with paging; 10,303 items across four lists read on a live tenant | The row stays, flagged with sp_deleted_at, by default | Your machine, your server or your own Azure | Licence per installation and destination family, quoted after a call | Yes: desktop app, command line or your Azure |
| SSIS with a SharePoint component | List items, through an OData source or a third-party component | Into whatever the package writes; the third-party components can also write to lists | Ids or text, joined inside the package | A SQL Server Agent job | Depends on how the source component pages through the list | Missed unless the package compares full loads or reads the recycle bin | A Windows server running Integration Services, or the Azure-SSIS Integration Runtime in Data Factory | Ships with SQL Server; a third-party component carries its own licence | Yes |
| CData Sync | Lists, through its SharePoint driver | Replication to a destination, SQL Server among them | Generic column mapping; the relational structure is up to you | Scheduled replication | Not covered by our comparison | Depends on the sync mode set for each connection | On-premises, in the cloud or both; CData Sync Cloud is the SaaS option | Annual licence sized by connections and a monthly row band | Yes |
| Skyvia | Lists, through Skyvia's SharePoint connector | One way or two-way | Relation mapping you configure | Depends on the plan | Not covered by our comparison | Configurable per integration | Skyvia's cloud; on-premises sources through Skyvia's agent | Plans with a monthly record allowance | No; Skyvia is always cloud-hosted |
| Layer2 Cloud Connector | Lists, online or on-premises | One way or two-way | Generic field mapping | Scheduled | Not covered by our comparison | Configurable per connection, including two-way delete propagation | A Windows Service you host | Licence per connector or data provider | Yes |
| Power Automate and Logic Apps | Items and files, an action at a time | Whichever way each flow was built | Each field mapped by hand inside the flow | On each item event, or on a recurrence | Get items needs pagination switched on, and the cap follows the performance profile | A second flow on the deletion trigger, open to site collection admins only | Microsoft's cloud, plus a gateway to reach an on-premises SQL Server | Per-user or per-flow plans; the SQL Server connector is Premium | No |
| Azure Data Factory | Lists, through the SharePoint Online List connector | Out of SharePoint into a pipeline sink | Lookup and person columns arrive as Int32 ids | A pipeline trigger you configure | A filtered query on an unindexed column can hit the threshold | Not documented for the list connector | Azure | Azure billing by activity and integration runtime | No; it is an Azure service |
| Fabric Dataflow Gen2 and Copy job | Lists, through the SharePoint Online List connector | Into Fabric items, Azure SQL or SQL Server, depending on the tool | Not documented as relational keys | Dataflow Gen2 refreshes up to 48 times a day; Copy job is full load only | A filtered query on an unindexed column can hit the threshold | A Copy job's full load keeps no record of removed items | A Fabric capacity | Fabric capacity units | No |
| Fabric mirroring (not SQL Server) | Lists, into Delta tables in OneLake, in preview | One way, into OneLake only | Learn does not say how lookup columns arrive | Continuous, near real time by Microsoft's account | Learn publishes no limitations page for this source | Not described on Learn's SharePoint list pages | A running Fabric capacity | Replication compute is free; queries draw on your capacity | No |
| PnP PowerShell and Python scripts | Whatever the script asks Graph or the REST API for | Whatever the script writes | Code you write and then maintain | Task Scheduler, cron or a CI job | Paging works; filtering on an unindexed column still trips the threshold | Detection is yours to write | Any machine that runs the script | The tools are free; the engineering time is the bill | Yes |
| Fivetran | Lists, with files on a separate connector | Out of SharePoint into a destination, SQL Server among them | Not documented as relational keys | A managed schedule on an interval you choose | Not covered by our comparison | See the connector's documentation on delete capture and history mode | Fivetran's cloud | Usage-based, on Monthly Active Rows | No; Fivetran is always hosted |
| Peliqan | One list per connection, through its Sharepoint List connector | Into its own warehouse or one you connect, SQL Server among them; Python scripts can also write to lists | Not described on its SharePoint pages | Incremental where the connector supports it, on a schedule set by the plan | Not covered by our comparison | Not described on its SharePoint pages | Peliqan's hosted platform | Per data source on its entry plan, flat on Pro, custom on Enterprise | No; Peliqan is a hosted platform |
| Airbyte | Lists, through the SharePoint Lists Enterprise connector | Out of SharePoint into a destination, SQL Server among them | Not documented as relational keys | Incremental on a modified-date cursor | Not covered by our comparison | Depends on the connector; see its documentation | Airbyte Cloud, or a platform you run yourself | Airbyte's plans; the open-source core is free to self-host | Yes, the platform |
Microsoft sources, checked on 23 October 2026: the list view threshold, Power Automate limits, the SharePoint connector reference, the SQL Server connector reference, the Data Factory SharePoint Online List connector, the Fabric connector overview, Dataflow Gen2 refresh and mirroring a SharePoint list in Fabric. Vendor details come from each comparison page, where every figure carries its source and the date we checked it.
What each tool does well, and where it stops
SPSync
SPSync replicates the lists and library metadata you pick, one way, into SQL Server or
Azure SQL, and SharePoint stays the system of record. After the first full load it
reads only what changed through Graph delta queries, every five minutes by default,
with a reconcile that re-checks every item, weekly by default, as quality assurance
and for recovery after an outage. Lookups arrive as key columns, multi-value columns as
child tables, and a deleted item keeps its row with sp_deleted_at set. In
testing against a live tenant it read 10,303 items across four lists, one of
them past the threshold. It runs as a desktop app on Windows or macOS, as a
command-line tool on your own server, or in your own Azure subscription. It copies no
file contents and writes nothing back to SharePoint. The
SharePoint to SQL Server and
SharePoint to Azure SQL pages show the tables
it creates.
SSIS with a SharePoint component
If your warehouse already runs on Integration Services, adding the list as one more package keeps everything under SQL Server Agent, next to the jobs your DBA already watches. The list comes in through an OData source or a third-party SharePoint component. Among those components, KingswaySoft's read list items and write lookup and taxonomy fields, and ZappySys sells an SSIS and ODBC connector for SharePoint Online sites, lists and libraries. Lookups arrive as ids or text for the package to join, a deleted item is only noticed if the package compares one full load with the last or reads the recycle bin, and the package metadata needs a refresh whenever someone changes a column. How a large list behaves depends on how the component pages through it. SPSync vs SSIS for SharePoint Online lists covers the components in full, and the SSIS column of the SharePoint to SQL Server route table sets them against PowerShell, flows and Data Factory.
CData Sync
CData Sync reaches SharePoint through one of its many drivers and replicates to a long list of destinations, SQL Server among them. It suits a team that wants one product for dozens of sources and is happy to model SharePoint's columns itself, since lookups, people and multi-choice columns map through a generic column schema. You can run it on-premises, in the cloud or both, and it is licensed annually by connections and a monthly row band. SPSync vs CData Sync covers where each fits.
Skyvia
Skyvia is a cloud service whose SharePoint connector syncs lists with SQL Server and other databases, one way or both ways. Two-way sync is something SPSync does not do, so if edits made in SQL Server have to reach the list, Skyvia is worth a look. Lookups need relation mapping you set up, how often it runs depends on the plan, and the plans carry a monthly record allowance. SPSync vs Skyvia sets out the plans and how a conflict is settled.
Layer2 Cloud Connector
Layer2 Cloud Connector runs as a Windows Service you host and syncs SharePoint, online or on-premises, with SQL databases and many other systems, in one direction or two. It is the stronger choice when deletes and edits must flow back into the list. Fields are mapped one to one, so lookups and multi-value columns are yours to shape, and it is licensed per connector or data provider. SPSync vs Layer2 Cloud Connector goes further.
Power Automate and Logic Apps
Flows are good at reacting to one item: an approval, a Teams message, a row inserted when a form is submitted. Keeping a whole SQL Server table in step with a whole list is a different job. Each item is its own action, field mappings are built by hand, and deletes need a second flow on the deletion trigger, which Microsoft's SharePoint connector reference limits to site collection admins. Get items must have pagination switched on, and Microsoft's Power Automate limits cap paginated items according to the performance profile. The SQL Server connector is Premium, and reaching an on-premises server goes through the on-premises data gateway. SPSync vs Power Automate and Logic Apps sorts the flows worth keeping from the ones worth retiring.
Azure Data Factory
Data Factory fits when the list is one source among many in a pipeline estate you already run, and Azure SQL is a natural sink for it. In the documented type mapping for the SharePoint Online List connector, lookup and person columns arrive as Int32 ids with no display value, and the connector says nothing about deletes, so the pipeline has to resolve both. It is billed through Azure by activity and integration runtime. SPSync vs Azure Data Factory and the Data Factory, Fabric, Power Automate or a replica guide take the choice one question at a time.
Fabric Dataflow Gen2 and Copy job
The Fabric data tools read lists through the same SharePoint Online List connector and can write to Azure SQL or SQL Server as well as to Fabric items. Microsoft's Fabric connector overview lists the Copy job as full load only, so each run reads the whole list again and keeps no record of what was removed. Dataflow Gen2 can refresh up to 48 times a day. Both draw on your Fabric capacity. SPSync vs Fabric mirroring, Dataflow Gen2 and Copy jobs compares them in detail.
Fabric mirroring (not SQL Server)
Microsoft can now mirror a SharePoint list into OneLake continuously, as Delta tables with a read-only SQL analytics endpoint. The SharePoint List source is a preview in Microsoft's mirroring overview. It needs a running Fabric capacity, and replication compute carries no charge. It does not write to SQL Server or Azure SQL, so it answers a different question: if every report already lives in Fabric, it is a strong default, and if the list has to sit in your SQL Server next to the ledger, it does not get you there. SharePoint to Microsoft Fabric covers the Fabric case.
PnP PowerShell and Python scripts
A script gives you total control and costs nothing to download, and a nightly export into SQL Server is a morning's work. The cost comes later, once people rely on it. Lookups, multi-value columns, delete detection, throttling and retries, a scheduler and the alert when it fails all become code that someone owns. SPSync vs PnP PowerShell and custom scripts lists what you take on, and what it costs to keep an export script running prices it.
Fivetran
Fivetran syncs lists through its Microsoft Lists connector, with files on a separate SharePoint connector, into a managed pipeline that can write to SQL Server. It runs in Fivetran's cloud on a schedule you choose and is priced on Monthly Active Rows, so cost follows how many rows change. Lookups are not documented as relational keys. SPSync vs Fivetran covers the pricing model and the connector's delete handling.
Peliqan
Peliqan syncs one SharePoint list per connection into its own hosted warehouse, and its SharePoint guide names SQL Server among the warehouses you can connect in its place. Around the copy it adds a SQL editor, BI connections, Python scripts that can add and update list items, and an MCP server with text-to-SQL and RAG. Its pages say sync is incremental where the connector supports it, and do not describe lookups or deletes. The entry plan is priced per data source. SPSync vs Peliqan sets out where each fits.
Airbyte
Airbyte lists a SharePoint Lists connector among its Enterprise connectors and reads incrementally on a modified-date cursor. Its open-source core is free to self-host, and Airbyte Cloud runs it for you. Lookups are not documented as relational keys, and how deletes are handled depends on the connector. SPSync vs Airbyte sets out where it fits.
What is the best way to sync a SharePoint list to SQL Server?
Start with what the copy is for. If a flow reacts to one item at a time and the table feeds no reports, keep the flow. When the list is one input to a larger SSIS or Data Factory job, it belongs in that job. If edits made in SQL Server have to reach the list, you need a two-way tool such as Skyvia or Layer2, because SPSync only copies one way.
The harder case is the copy people read every day: a report, an app or an agent querying SQL Server instead of SharePoint. For that copy, ask four things of each tool. Does a lookup arrive as a key you can join on? When an item is deleted, is there still a record of it in the table? Can the read get past the list view threshold without indexing columns to suit it? And who owns the schedule, the credentials and the alert when a run fails? The table above answers the first three for each tool as it ships, and the last is usually what decides it.
How the copy looks in SQL Server
In an SPSync copy, each lookup is written as two columns, {col}_id and
{col}_value, and each person as a key into one shared
sp_users table, as the schema reference
sets out. Generated reporting views leave deleted rows out, so a report sees current
items while an auditor can still find what was removed and when.
What breaks past 5,000 items
explains why reading changes by delta avoids the threshold.
Azure SQL Database and Managed Instance run the same engine as SQL Server, so the tables and the sync are the same for either. SPSync signs in to Azure SQL with SQL authentication over an encrypted connection; Microsoft Entra authentication is not wired up yet. SharePoint to Azure SQL covers the firewall and Managed Instance details.
Other destinations and other routes
This page covers SQL Server and Azure SQL only. SharePoint list to a database: every route compared covers PostgreSQL, MySQL, Oracle, warehouses and the routes that read a list in place, such as Excel links, Power Query and Dataverse virtual tables. The comparison hub lists every one-to-one comparison on the site.