Choose SPSync when an AI tool or app needs structured rows, filters and joins over list data; choose SharePoint search for finding documents and quick lookups across Microsoft 365.
Documentation reviewed
Where SharePoint search fits
- Already indexed by SharePoint or Microsoft Search, nothing extra to build
- no separate infrastructure needed
- good for keyword lookup and document-discovery style UIs
- one unified endpoint across Outlook, OneDrive and SharePoint
Where it breaks
- Returns ranked search hits, not structured rows you can query
- no joins across lists or between search results and other data
- results depend on crawl freshness and are subject to throttling like any other Graph call
- no vectors or embeddings you control for retrieval-augmented generation
- only surfaces content that has actually been crawled and indexed
Feature by feature
| Feature | SPSync | SharePoint search and the Graph search API as an AI source |
|---|---|---|
| SharePoint Online support | Core product | Yes, as a search index over SharePoint content |
| On-prem SharePoint support | On the roadmap | SharePoint Search REST API supports on-prem; Graph search API does not |
| 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/ | None; it is a query endpoint and replicates nothing |
| Lookup normalisation | Lookups become joinable key columns | Not applicable; search results are ranked documents, not relational rows |
| Multi-value columns | Child tables | Not applicable |
| Deletes | Soft delete by default, hard delete with the command-line tool | Removed items drop out once the crawl catches up |
| Delta sync | Every few minutes by default, plus a reconcile, weekly by default | Depends on SharePoint's own crawl schedule |
| Schema evolution | New columns appear automatically; on SQL Server, PostgreSQL, MySQL, ClickHouse, Oracle, SQLite and DuckDB retyped columns get a _v2 column | Not applicable; there is no schema to evolve |
| Hosted option | SPSync in your Azure | Always hosted, as part of Microsoft 365 |
| Desktop app | macOS and Windows | None |
| CLI / CI | Built-in CLI | Callable via REST; it does not replicate |
| Per-site least-privilege permissions | Delegated sign-in or app-only with Sites.Selected, bring-your-own-app | Search results respect the querying user's existing permissions |
| Pricing model | Licensed per installation and per target family, on annual terms, with Standard Support included; no public price list, quoted after a call | Included with Microsoft 365/Graph licensing |
Search is already there. For “find me the document” lookups, or a Copilot-style assistant answering from what SharePoint has indexed, querying search live is the path of least resistance. It needs nothing built or maintained, results are trimmed to what the querying user can see, and Microsoft’s unified search endpoint covers Outlook, OneDrive and SharePoint together. For light, ad hoc document discovery that is often enough.
Ranked hits are the limit
It stops being enough when you need structured answers. Search returns documents and snippets, which you cannot filter, aggregate or join against other data the way you can rows, and there is no relational schema to query with SQL. Results depend on how current the crawl is and are throttled like any other Graph call. For AI grounding in particular, an index you build and control, for example in Azure AI Search, gives you retrieval behaviour you can tune and monitor yourself.
Rows and an index you control
SPSync replicates list items and document-library metadata into a database, kept current every few minutes, so an application gets structured rows to query. For retrieval-augmented generation and semantic search, SPSync can write that metadata into a vector-capable store you control. Postgres with pgvector and Azure AI Search are shipped today, and Elasticsearch, OpenSearch, LanceDB, Qdrant and Weaviate are shipped SPSync destinations for keyword and filtered search, pending a wired-up embedding field. AI tools then read a retrieval source you own.
Teams move over when an AI tool or app needs structured, filterable data. The table sets out the other differences, including crawl freshness and throttling.
Dividing the work between search and SPSync
- Separate the use cases that need document discovery (keep using search) from those that need structured metadata or a retrieval index you control (move to SPSync).
- Connect SPSync to the site and choose the lists and libraries whose metadata you need.
- Choose a destination, including a vector-capable store if you are building retrieval for an AI tool, and set the sync schedule.
- Wire the AI tool or app to query the new tables or index.
- Keep SharePoint search for document lookup; the two serve different jobs and often run side by side.
SPSync as a SharePoint search alternative for SharePoint lists
SPSync gives AI tools rows and an index you control: list items and library metadata replicated into a database, or into pgvector or Azure AI Search for retrieval. Search stays in place for document discovery, and the two usually run side by side.
Other alternatives
- CData Connect AI: answers agents live over MCP, so every question reaches SharePoint at the moment it is asked.
- Peliqan: an MCP server, RAG and text-to-SQL over SharePoint lists, run from its own hosted warehouse.
- Coupler.io: connects Microsoft Lists to AI assistants such as Claude, ChatGPT and Copilot through its own integrations.
- Microsoft Graph Data Connect: bulk, governed exports of file and activity datasets for analytics, with no list items dataset.
Frequently asked questions
Can the Microsoft Search API return SharePoint list items?
Yes. Microsoft's overview names list, listItem, site and drive resources among the SharePoint content the Search API covers (checked 2026-10-22). What comes back is a ranked set of hits for a query, which you cannot join, aggregate or filter the way you can rows in a table.
Does the SPSync copy respect SharePoint permissions?
No. Search trims results to what the person asking may see, and the SPSync replica carries no item permissions. Control access in the database with read-only roles and row-level security, or keep permission-sensitive lookups on search.
Which vector stores can SPSync write to?
Postgres with pgvector and Azure AI Search take embeddings today. Elasticsearch, OpenSearch, LanceDB, Qdrant and Weaviate are shipped destinations for keyword and filtered search, with their embedding field still to be wired up.
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.