SharePoint to Snowflake

Last updated 23 October 2026

Status: Coming soon · product: SPSync for Warehouses & Lakes . We prioritise destinations by demand. Book a call to tell us you need it.

SPSync copies SharePoint lists one way, out of SharePoint into a store you query, and SharePoint stays the system of record. Snowflake is on the roadmap as one of those stores but is not one of them today, so SPSync cannot write to Snowflake directly. Teams still get list rows into Snowflake on a schedule: a shipped SPSync destination writes Parquet files, and Snowflake’s own tools load them.

Is there a SharePoint list connector for Snowflake?

Not for list items. Snowflake’s Openflow Connector for SharePoint is generally available and takes files from a SharePoint site, with or without their permissions, into a Snowflake stage or a Cortex Search service. That works for PDFs and Office documents an assistant should read. It does not read the rows of a SharePoint list, so a tracker, a register or an approvals list does not arrive in Snowflake as a table. We read Snowflake’s documentation on 22 October 2026, and Openflow changes often, so check the page again before you plan around it. Our post on what Openflow and Databricks Lakeflow do with SharePoint lists sets the two connectors side by side.

The native connector ingests files. SPSync replicates list items, and today it gets them to Snowflake through Parquet.

Staging through Parquet

This route ships today. A DuckDB destination can export every table as Parquet to Amazon S3, Azure Blob or ADLS Gen2 at the end of each run, and the ADLS Gen2 destination writes the same layout to a container. Each table gets a current.parquet file that is replaced every run.

From there, Snowflake does the rest:

1. Create an external stage over the bucket or container.
2. Load current.parquet with COPY INTO, let Snowpipe pick up each new file, or define an external table over the stage and query the files where they sit.
3. Because each file is a full snapshot, replace the target table’s contents on each load, or merge on sp_item_id.

Deleted items are in the snapshot with sp_deleted_at set, so filter or carry the flag into your models. Snowflake’s MATCH_BY_COLUMN_NAME option keeps the load working when a new SharePoint column appears in the file.

Snowpipe works on new files, so point it at the per-run history files if you want each run appended as it arrives, and reconcile the table to the latest snapshot in a task. The replaced current.parquet is simpler to reason about for a scheduled COPY INTO.

Staging through a database

If you already run an ELT tool that reads PostgreSQL or SQL Server into Snowflake, point SPSync at one of those and let the tool move the tables on. You keep SPSync’s delta sync and soft deletes on the first hop, and your tool’s scheduling on the second.

Questions a native destination has to answer

The table shapes would not change: {col}_id and {col}_value for lookups, {col}_user_id joined to sp_users for people, a child table per multi-value column, as on every shipped destination and in the schema reference. The open points are Snowflake’s own:

• staged files with COPY INTO, or a streaming path;
• key-pair or other authentication for an unattended service user;
• whether a raw JSON column is offered beside the typed ones.

Those have not been decided, and this page will say nothing about them until they are built.

Ask for it

Get in touch and describe the layout you have in mind: database, schema, how many lists and how many rows, and how fresh the data needs to be. Requests like yours set the order of the roadmap, and we will tell you as soon as Snowflake ships, in all three editions at once.

# This destination has no --destination-kind in the command line today.
# In the meantime, run this from a shipped destination (Postgres or SQL Server)
# and repoint --connection-string-env at your database.

# YAML for this destination's kind ships with its --destination-kind support.

# every night at 02:00
0 2 * * * cd /opt/spsync && SPSYNC_DB_CONNECTION="$(cat /etc/spsync/db.env)" uv run spsync run replication.yaml >> /var/log/spsync/run.log 2>&1

# .github/workflows/spsync-run.yml
name: SPSync
on:
  schedule:
    - cron: "0 2 * * *"
  workflow_dispatch: {}
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync
      - run: uv run spsync run replication.yaml
        env:
          SPSYNC_DB_CONNECTION: ${{ secrets.SPSYNC_DB_CONNECTION }}
          SPSYNC_LICENCE_KEY: ${{ secrets.SPSYNC_LICENCE_KEY }}

# azure-pipelines.yml
schedules:
  - cron: "0 2 * * *"
    branches: { include: [main] }
    always: true
steps:
  - script: uv sync
  - script: uv run spsync run replication.yaml
    env:
      SPSYNC_DB_CONNECTION: $(SPSYNC_DB_CONNECTION)
      SPSYNC_LICENCE_KEY: $(SPSYNC_LICENCE_KEY)

# Windows Task Scheduler action (see /docs/cli/automation/)
$env:SPSYNC_DB_CONNECTION = (Get-Content C:\spsync\db.env)
uv run spsync run C:\spsync\replication.yaml
schtasks /Create /SC DAILY /ST 02:00 /TN "SPSync" /TR "powershell -File C:\spsync\run.ps1"

# ~/Library/LaunchAgents/io.spsync.run.plist, then: launchctl load ~/Library/LaunchAgents/io.spsync.run.plist