SPSync vs Stacksync

Choose SPSync when SharePoint lists are the source and you want them in Postgres as joinable tables; choose Stacksync for two-way sync between CRMs, ERPs and databases where SharePoint plays no part.

Documentation reviewed 23 October 2026

Where Stacksync fits

• Real-time two-way sync between CRMs, ERPs and databases, priced the same as one-way sync
• Genies, its AI agents, can pause for a person to approve a write, and plans include MCP access
• SOC 2 Type II and ISO 27001 on the Pro plan and above, which helps when procurement asks for paperwork
• alerts over email, Slack, PagerDuty and WhatsApp, with retry and revert from an issues dashboard

Where it breaks

• its own PostgreSQL and SharePoint page says SharePoint support is not established, and marks both sync directions for confirmation
• the developer documentation has connector guides for Postgres, Salesforce and HubSpot and has no page for SharePoint
• the SharePoint pages say nothing about the list view threshold, lookup columns, person or managed metadata columns, Graph throttling or delta queries
• Postgres tables need a single-column primary key that the database generates, and renaming a schema, table or column breaks the sync configuration
• plans are metered by records in sync, so a growing list moves you up the price table
• when both sides change the same record, the most recent change wins

Feature by feature

Search for a way to keep a SharePoint list and a PostgreSQL database in step and a Stacksync integration page is likely to sit near the top. It has a mapping worksheet and a button to book an engineer, so at a glance it reads like a product page. The detail halfway down is worth reading before you book that call.

Does Stacksync support SharePoint?

Not on the evidence of its own pages. The PostgreSQL and SharePoint page says, in its words, “Stacksync support for SharePoint is not established by the connector documentation reviewed for this page” (stacksync.com/integrations/postgresql-and-sharepoint, checked 2026-10-23). Both sync directions on that page are marked for confirmation, and the SharePoint connector page says write-back is not established either. We looked through their developer documentation and found guides for Postgres, Salesforce, HubSpot and Snowflake, and nothing for SharePoint.

We would not read that as a weak product. Stacksync’s core is two-way sync between CRMs, ERPs and databases, and where a connector is documented the detail is specific. The Postgres guide, for example, spells out logical replication and which primary keys it accepts.

What a SharePoint list asks of a sync tool

SharePoint has habits a general connector has to learn. Lookups arrive as an ID and a display value, and multi-value columns arrive as arrays. Once a list passes 5,000 items, any query on a column without an index runs into the list view threshold, while Microsoft Graph throttles a client that asks too often. The Stacksync SharePoint pages mention none of this.

The Postgres side has rules of its own. Each table needs a single-column primary key that the database generates, and renaming a schema, table or column breaks the sync configuration until someone updates it by hand.

SharePoint to PostgreSQL with SPSync today

SPSync reads each list through Microsoft Graph delta queries and writes the changes to Postgres every few minutes. A reconcile, weekly by default, compares the whole list with the replica, which is your quality check and also how the copy catches up after an outage. Lookups become key columns you can join on and multi-value columns become child tables, so the schema is ready for reports and apps without you designing a mapping. We have run it against lists well past the threshold on a live tenant, and the delta reader pages through them without hitting it.

The trade-off is direction. SPSync is read-only against SharePoint, so an app that writes to the Postgres copy changes the copy and nothing else. Write-back is designed, with per-list opt-in and SharePoint winning any conflict, and it is on the roadmap. If you need rows written back to a list this quarter, Layer2 Cloud Connector does that now.

What can Stacksync AI agents do with SharePoint data?

Stacksync is ahead on agents. Its Genies read across the systems you connect and act on them, and you can put an approval step in front of any write so a person signs it off first. Genies are sold as their own AI Agents plan, which includes MCP access, and Stacksync has announced Stacksync MCP, which gives Claude, Cursor and other MCP clients governed access to your syncs, workflows and connections (checked 2026-10-23). For CRM and ERP work that is a real head start.

Its AI agents page makes the case SPSync is built on. An agent that calls each SaaS API on every question burns API calls and tokens, so Stacksync keeps a current copy of the records in a database the agent can query. SharePoint shows up in the long connector list on that page, yet the SharePoint pages themselves still say support is not established, so a Genie working on list data stays unproven until Stacksync documents the connector.

SPSync ships no agent. What it gives you is one SQL copy of your lists, read from SharePoint by delta query and never written back. An agent reaches it through a Postgres MCP server you choose, or through spsync mcp serve, SPSync’s own read-only MCP server, signing in with a read-only database login instead of a Microsoft Graph permission. SharePoint item permissions are not carried into the replica, so row-level security and scoped roles decide what each agent can see. For retrieval over item text, SPSync can generate embeddings on each sync into pgvector or Azure AI Search, and no other destination today. It copies metadata, not file contents.

Choosing between them

Pick Stacksync when the systems in play are Salesforce or HubSpot and a database and you want writes flowing both ways. Its SOC 2 report also helps if procurement asks. Prices are published, and the Starter plan covers one active sync and 50,000 records in sync, with the bill rising as the record count grows. A record counts once a month however often it changes, which is fair to busy tables.

Pick SPSync when SharePoint lists are the source and you want them in Postgres, or another database, as tables that join. The replica sits in a database you run, and the licence is per installation and per target family, so the size of the list does not move the bill.

Trying SPSync on the same list

1. Take the list you would have brought to the Stacksync scoping call, or the one with the most rows.
2. Sign in to SharePoint in SPSync and tick that list.
3. Choose your Postgres database and let the first full load run; delta sync keeps it current after that.
4. Join a lookup column to its target table and check the row counts against the list.
5. If write-back matters to you, tell us on a call so it shapes the roadmap.

SPSync as a Stacksync alternative for SharePoint lists

SPSync is a documented SharePoint route for the Postgres project Stacksync's pages describe. It reads lists by delta query, writes lookups as keys and multi-value columns as child tables, and runs a reconcile, weekly by default, as your quality check. Writing back to lists is on the roadmap.

Other alternatives

• Layer2 Cloud Connector: the established choice for writing rows back into SharePoint lists today.
• Skyvia: two-way sync between a list and a database, as often as once a minute on its top plan.
• Peliqan: SharePoint lists in a hosted warehouse with AI tooling on top, plus Python scripts that can add and update list items.
• Coupler.io: scheduled Microsoft Lists loads into PostgreSQL and Supabase, managed in its own cloud.