Power Apps reading SQL for large lists, with SharePoint still where people edit

Last updated 23 October 2026

A Power App built on a large SharePoint list hits delegation warnings, slow galleries and inconsistent filtering once the list grows past a few thousand items.

Power Apps has a data row limit, 500 by default and at most 10,000 items, and on a SharePoint list most filters, sorts and searches stop at it. Power Apps delegates only a small set of operations to SharePoint; anything else pulls rows into the app up to that limit and leaves the rest out without an error. A site inspection app on a list of a few thousand inspections shows the symptom: searching for an older inspection finds nothing. Indexing columns and simplifying formulas raise the ceiling a little and leave it in place. Our post on Power Apps past the data row limit compares what SharePoint and SQL Server each delegate, formula by formula.

Read from SQL, keep editing in SharePoint

SPSync replicates the list into SQL Server or Azure SQL, and Power Apps delegates a much wider set of operations to those. The galleries, filtered views and lookup screens read the replicated table, and the delegation warnings on those screens mostly go away.

SharePoint stays the place people edit. SPSync only reads, so the list, its forms and the Power Automate flows built around it keep working as before. The app’s edit form keeps writing to SharePoint, and the next sync brings the change into the table.

Why the formulas start behaving

The list arrives as a table with the same columns. A lookup is a key column with its display value beside it, so filtering or sorting a gallery on a lookup field gives the same answer every time. Multi-value columns are child tables. Formulas that used to change behaviour depending on which field they touched now run against a stable SQL schema. Deleted inspections keep their row with sp_deleted_at set, which is useful for a “recently removed” screen or an audit view.

Repointing the app

Pick the site, the inspections list and any lists the app’s filters look up to. Choose SQL Server or Azure SQL and let SPSync create the schema. Set a schedule short enough that a just-saved inspection appears in the gallery before the engineer goes looking for it; every few minutes is typical. Then switch the read-only screens to the replicated table and leave the edit forms on SharePoint.

A proof of concept can run from the desktop app on one machine. Once the app is in production, its data source should not depend on anyone’s laptop, which is what SPSync in your Azure is for.

spsync auth login --client-id 00000000-0000-0000-0000-000000000000
spsync export-config --output replication.yaml --pipeline-name power_apps_performance --prefix power_apps_performance --destination-kind mssql --connection-string-env SPSYNC_DB_CONNECTION --dataset-name power_apps_performance --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: power_apps_performance
prefix: power_apps_performance
auth:
  mode: delegated
  client_id: 00000000-0000-0000-0000-000000000000
  tenant_id: common
destination:
  kind: mssql
  connection_string_env: SPSYNC_DB_CONNECTION
  dataset_name: power_apps_performance
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