SPSync vs CData Sync

Choose SPSync when SharePoint lists are the main source and you want the relational mapping done for you; choose CData Sync when one licence has to cover dozens of other systems as well.

Documentation reviewed 23 October 2026

Where CData Sync fits

• a broad connector catalogue in one platform
• published annual pricing sized by connections and a monthly row band
• flexible deployment: on-prem, cloud or hybrid
• change data capture across many sources
• a separate product, CData Connect AI, answers Copilot Studio and n8n from live SharePoint data over MCP, and is now presented as a governed AI gateway built on its enterprise MCP platform

Where it breaks

• SharePoint is one driver among hundreds, not a purpose-built product
• lookups, people and multi-choice map through a generic ADO.NET-style schema, not automatic relational normalisation
• connection-based licensing, so cost follows the number of connections
• SharePoint-specific mappings are configured within the platform rather than provided automatically
• Connect AI's live queries reach SharePoint on every call, so they draw on the tenant's throttling budget and meet the 5,000-item view threshold on large lists
• per-user passthrough identity in Connect AI is a Business plan feature

Feature by feature

CData Sync makes its case on breadth. An integration estate that spans dozens of systems, with SharePoint lists as one of them, can run on one platform with one connector catalogue and one licence. You can deploy it on-prem, in the cloud or across both, and change data capture makes it a reasonable default for a team standardising on a single replication platform across many source types.

SharePoint through a generic driver

That breadth comes from a generic driver architecture, and SharePoint lists are not its speciality. Lookup, person, choice and managed-metadata columns pass through the same general-purpose schema mapping as every other source. Turning a lookup into a joinable key, or a multi-value column into its own table, is work you configure; we did not find it documented as automatic. Pricing is connection-based, so several SharePoint sites may mean several connections.

Built around SharePoint’s columns

SPSync starts from SharePoint’s own column types. Lookups become key columns you can join on and multi-value columns become child tables, with people resolved into a shared sp_users table, so there is no mapping to write. Delta sync runs every few minutes by default with a reconcile behind it, weekly by default. A column added in SharePoint appears in the destination automatically, and deleted items are flagged and kept.

The case for switching rests on the mapping work a generic driver leaves behind, which across a handful of SharePoint sites can outweigh the convenience of one platform. The table compares licensing and the desktop app.

How does CData Connect AI reach SharePoint for AI agents?

CData now sells a second route to SharePoint for AI work. Connect AI is a remote MCP server. You add a SharePoint connection in CData’s cloud, add the Connect AI tool to a Copilot Studio agent or an n8n workflow, and the agent runs SQL that CData turns into requests against the list at the moment someone asks. CData’s Copilot Studio walkthrough says this happens “without the need for data replication”, with filters pushed down to SharePoint (checked 2026-10-20). The Connect AI home page now introduces Connect AI Gateway, “one governed path between your agents and every system you run”, built on CData’s enterprise MCP platform. It puts cost controls and guardrails on every model, tool and agent call, checks the identity of each user and agent, and names Claude Code, Copilot, Cursor and LangChain among the agents it works with. The page asks visitors to request early access. We read it from the newest Internet Archive copy, because cdata.com refuses automated requests (checked 2026-10-23). Live querying is the opposite pattern to SPSync, so it deserves a straight comparison.

Live has two real advantages. The answer reflects an edit made seconds ago, where a replica is as fresh as its last delta run, every few minutes by default. On Connect AI’s Business plan, passthrough identity runs each query as the person asking, so SharePoint’s own permissions decide what the agent sees. SPSync does not copy SharePoint permissions into the replica; you bound what an agent reads with a read-only database role and row-level security instead.

The costs grow with use. Every question becomes requests against your tenant, and an agent often makes several tool calls to answer one, all drawn from the same throttling budget as your users and your other integrations. SharePoint refuses a filter on an unindexed column once a list passes the 5,000-item view threshold, so a live route needs that column indexed or has to page through the whole list and filter afterwards. Lookup display values are expanded on each request instead of being stored once. Connect AI’s own pricing page lists a query cache that copies large datasets into a Postgres database you provide.

When live MCP is the right choice

Choose a live route such as Connect AI when questions are occasional and the lists are small, or when the answer has to match the list to the second. It is also the better fit when each person must see only the items SharePoint lets them see and you are on the Business plan, because SPSync’s replica does not carry item permissions today.

Choose the replica when many readers share the same lists, or when questions run across large lists and joins. SPSync reads each change once by delta query, and every reader then queries your database, so a busy afternoon of agent questions costs the tenant nothing extra. SPSync ships no agent. Point a database MCP server at the replica, or run spsync mcp serve, SPSync’s own read-only MCP server, and give the agent a read-only database login, so the agent never holds a Microsoft Graph permission and answers from the replica alone. A database MCP server never touches SharePoint; spsync mcp serve reads the list definitions from SharePoint once when it starts, with SPSync’s own sign-in, which the agent never holds. For retrieval over item text, turn on embeddings and SPSync writes vectors on each sync into pgvector or Azure AI Search, the two destinations that support it today. You can also run both, keeping Connect AI for the few questions that need the live list.

Handing the lists over to SPSync

1. Keep your CData Sync connections for other sources as they are.
2. Sign in to SharePoint in SPSync and select the lists the CData connection reads.
3. Pick the destination database, let the first full load run and then set how often delta runs happen.
4. Compare the SPSync tables with your CData-built ones, especially lookup and multi-value columns, then repoint downstream queries.
5. Retire the SharePoint connection in CData Sync when the two agree, which frees that connection licence.

SPSync as a CData Sync alternative for SharePoint lists

SPSync takes over the SharePoint connection and nothing else. Lookups, multi-value columns and people arrive mapped without a configuration step, and the CData connection the lists used can go to another source or be dropped at renewal.

Other alternatives

• Skyvia: a cloud platform with a no-cost entry plan and two-way sync, sized by monthly record volume.
• Layer2 Cloud Connector: a Windows service built for two-way sync, the stronger pick when edits must flow back into a list.
• ZappySys: ODBC and SSIS drivers for SharePoint Online, close to CData's driver model and run from tools you already use.
• Peliqan: pairs SharePoint lists with its own hosted warehouse and adds an MCP server and text-to-SQL for AI work.