Choose SPSync when reports, apps or AI tools outside Power Platform need SharePoint lists as SQL tables; choose Dataverse virtual tables when one Power Apps app needs live list data inside Dataverse.
Documentation reviewed
Where Dataverse fits
- Native inside Power Apps, with delegation and formulas working as expected
- always current, since every read passes through to SharePoint live
- no separate data store to build or maintain
- sits inside Dataverse's existing security model
Where it breaks
- requires Dataverse, licensed through Power Apps or Dynamics 365; check Microsoft's licensing guide for your plan
- not a copy, so you cannot query it freely with plain SQL or join it against other databases
- every query still hits SharePoint live, so it inherits SharePoint's own throttling and latency
Feature by feature
| Feature | SPSync | Dataverse and virtual tables |
|---|---|---|
| SharePoint Online support | Core product | Yes, as a virtual table source |
| On-prem SharePoint support | On the roadmap | No |
| Destinations | Relational, warehouse, lake and search/vector destinations: 20 destination engines (30+ named targets such as Azure SQL, MariaDB and Supabase), including SQL Server, Postgres, BigQuery, Databricks, ClickHouse, Parquet, Iceberg, pgvector and Azure AI Search; see /destinations/ | Dataverse only |
| Lookup normalisation | Lookups become joinable key columns in a database you run | Preserved inside Dataverse's own relationship model, not exportable to SQL |
| Multi-value columns | Child tables | Depends on how Dataverse column types map; see Microsoft's documentation |
| Deletes | Soft delete by default, hard delete with the command-line tool | Reflected live since there is no copy to fall behind |
| Delta sync | Every few minutes by default, plus a reconcile, weekly by default | Not applicable; reads pass through to SharePoint on demand |
| Schema evolution | New columns appear automatically; on SQL Server, PostgreSQL, MySQL, ClickHouse, Oracle, SQLite and DuckDB retyped columns get a _v2 column | The table definition is managed in Dataverse; see Microsoft's documentation |
| Hosted option | SPSync in your Azure | Dataverse is always hosted (part of Power Platform) |
| Desktop app | macOS and Windows | None |
| CLI / CI | Built-in CLI | Power Platform CLI for table definitions, not for data movement |
| Per-site least-privilege permissions | Delegated sign-in or app-only with Sites.Selected, bring-your-own-app | Connector-level SharePoint permissions plus Dataverse security roles |
| Pricing model | Licensed per installation and per target family, on annual terms, with Standard Support included; no public price list, quoted after a call | Dataverse licensing through Power Apps or Dynamics 365; see Microsoft's licensing guide |
Virtual tables let a Power Apps canvas or model-driven app treat a SharePoint list as a native Dataverse table. Delegation, formulas and relationships work the way app makers expect, and every read passes straight through to SharePoint, so there is nothing to keep in step. For a team already licensed for Dataverse that wants list data inside a Power Platform app without duplicating it, that is a low-effort choice.
What “no copy” means in practice
A virtual table is a window onto the list. You cannot query it with SQL, join it to other systems or hand it to a BI tool that expects a stable schema. Every read reaches SharePoint live, so performance and throttling follow SharePoint’s limits, with no cache of your own in between. Dataverse is also a requirement, licensed through Power Apps or Dynamics 365, so check Microsoft’s licensing guide for your plan.
A copy that anything can read
SPSync replicates the list into tables in a database you already run and keeps them current every few minutes. Lookups become key columns you can join on, multi-value columns become child tables, and the result answers plain SQL from Power BI, an app, a warehouse or an AI model. None of those readers needs a Dataverse licence or a Power Platform environment.
Teams add SPSync when the consumer is something other than a Power Apps canvas, such as a reporting tool that expects an ordinary SQL schema. Many keep both: virtual tables inside one app, and SPSync feeding everything else. If the wider question is whether a list should hold the data at all, our post on SharePoint as a database weighs a list against Dataverse and a SQL database with a decision table.
Splitting the work between the two
- Work out which consumers need the live pass-through (an app’s delegation logic, for instance) and which only need current data (most reporting and integration).
- Point SPSync at the site and lists behind the virtual table.
- Choose a destination database and a schedule; the first full load writes everything and delta sync keeps it current.
- Move reports, dashboards and integrations outside the Power Platform to the new SQL tables.
- Keep the virtual table for any app that still needs it. The two approaches can run side by side.
SPSync as a Dataverse alternative for SharePoint lists
SPSync sits beside a virtual table more often than it replaces one. The app keeps its live view of the list, and everything that wants a stable SQL schema, from Power BI to a warehouse load, reads a replica in a database you run.
Other alternatives
- Power Query: reads the list live into Excel or Power BI, quick for one report and slow once the list is large.
- Power Automate: copies items into Dataverse or SQL one action at a time as they change.
- Coupler.io: scheduled imports of Microsoft Lists into spreadsheets and BI tools, for teams whose readers live in Excel and dashboards.
Frequently asked questions
What happens to a virtual table when a SharePoint column changes?
Microsoft's guide says re-creating the virtual table picks up column changes made in the source, so a new column means a trip back through the table wizard (checked 2026-10-22). In SPSync a new column appears in the destination on the next run, and a column renamed in SharePoint keeps its original internal name in the database.
Can SPSync copy SharePoint lists into Dataverse itself?
Yes. Dataverse is one of SPSync's shipped destinations, which gives a Power Apps app a native Dataverse table with delegation over a copy of the list. The virtual table reads SharePoint live, while the SPSync table is refreshed every few minutes.
Do Power BI reports on the SPSync copy need Dataverse?
Only when Dataverse is the destination you picked. With the replica in Azure SQL, SQL Server or PostgreSQL, Power BI connects to it like any other SQL source and Dataverse plays no part.
Desktop, Azure or command line
All three editions run the same engine, write the same tables and use the same licence key, so the choice comes down to who looks after the sync.
Desktop app
For macOS and Windows. Sign in with Microsoft, tick the lists, choose a database and sync from your own machine on the schedule you set. Delegated sign-in needs no admin unless your tenant requires admin consent for apps.
In your Azure
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, so the sync keeps running with every laptop closed.
Command line
Every replication is a YAML file you can review and commit. Run it from a server, a container or a CI pipeline, and re-run it safely any time.