SharePoint to MariaDB

Last updated 19 October 2026

One way: SharePoint stays the system of record, and SPSync keeps a read-only copy of your lists current in MariaDB.

Status: Shipped · product: SPSync for Relational Databases

MariaDB often runs on servers its owners patch themselves, sometimes in place of an older MySQL installation. SPSync writes SharePoint lists into that same server, so the list data sits next to the systems that already use it and needs no extra service.

How SPSync talks to MariaDB

The destination is SPSync’s MySQL destination, with a mysql+pymysql:// connection string held in an environment variable. MariaDB has its own run in SPSync’s integration tests, against a MariaDB 11 server, because it differs from MySQL 8 in places such as JSON functions. The SQL SPSync issues today avoids those differences.

Sign-in is a MariaDB username and password. The user needs rights to create tables in the target database. If the server requires TLS, pass the CA certificate path as ssl_ca in the connection string.

Allow the network path from wherever the sync runs: a firewall rule, a security group, a VPN or a host on the same network.

Tables you can query

A spare-parts list with a Machine lookup, a Storekeeper person column, a Bin text column and a multi-choice Compatible models column becomes maint_parts, keyed on the SharePoint item ID. The lookup gives machine_id and machine_value. Each storekeeper is a storekeeper_user_id that matches a row in sp_users. The multi-choice column becomes maint_parts__compatible_models, a row per part and model. Names longer than 64 characters are shortened to fit MariaDB’s limit.

New SharePoint columns appear on the next run. Removed columns stay in the table. A column whose type changes keeps its history and gets a _v2 column alongside.

Where it is used

An open-source BI stack. Metabase and Grafana read MariaDB directly; see Tableau, Looker, Metabase and Grafana on SharePoint data.

An application on MariaDB. The app queries replicated tables with the same driver it uses for its own schema; see a read replica for internal apps.

Reference data. Approved vendors or product codes kept in SharePoint join to other tables on the same server; see reference and master data from SharePoint.

Leaving SharePoint lists. A current copy gives the application something to cut over to; see migrating list data off SharePoint.

Steps

1. Sign in with delegated access to try it, and switch to Sites.Selected app permissions, approved by an admin, for scheduled runs.
2. Store the connection string in an environment variable and name it in the destination settings.
3. Choose the lists, or a whole site so new lists are picked up.
4. Run. The first run builds the schema and loads everything.
5. Set a schedule, every few minutes up to hourly, with a reconcile, weekly by default.

The first full load of a large list moves far more data than any run after it, so start it at a time when the server is quiet.

spsync auth login --client-id 00000000-0000-0000-0000-000000000000
spsync export-config --output replication.yaml --pipeline-name mariadb --prefix mariadb --destination-kind mysql --connection-string-env SPSYNC_DB_CONNECTION --dataset-name mariadb --client-id 00000000-0000-0000-0000-000000000000 --site-url https://contoso.sharepoint.com/sites/example --all-lists
spsync doctor replication.yaml
spsync run replication.yaml

pipeline_name: mariadb
prefix: mariadb
auth:
  mode: delegated
  client_id: 00000000-0000-0000-0000-000000000000
  tenant_id: common
destination:
  kind: mysql
  connection_string_env: SPSYNC_DB_CONNECTION
  dataset_name: mariadb
scopes:
  - site_url: https://contoso.sharepoint.com/sites/example
    mode: entire_site
reconcile_interval_days: 7
create_reporting_views: false

# 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