You should move a Power App or flow off SharePoint lists to the Databricks connector for Power Platform the moment your data outgrows what a list can serve reliably — past the 5,000-item view threshold, into real governance requirements, or when the same numbers need to live in one trusted place instead of a copied list. The connector, generally available since June 23, 2026, lets Power Apps, Power Automate, and Copilot Studio read and write Databricks tables in real time while keeping Unity Catalog governance fully intact, so you stop maintaining a second copy of the data in a list nobody governs.

This guide is written for the Power Platform architects, operations leaders, and IT directors who built a canvas app on a SharePoint list, watched it hit a wall as the data grew, and now need a straight answer on whether Databricks is the right backend, what it costs to license, and where the connector’s real limits sit. It covers when the move is justified, how read and write actually work, the licensing trigger that catches teams off guard, and the governance and availability constraints you have to plan around before you commit.

Key Takeaways

• SharePoint lists fail on retrieval, not storage. A list stores up to 30 million items, but the 5,000-item view threshold and Power Apps’ 500–2,000 row delegation limit mean large lists return partial, silently wrong results.
• The Databricks connector went GA on June 23, 2026. It gives Power Apps, Power Automate, and Copilot Studio direct, real-time read and write access to Databricks tables with no data duplication.
• Write-back is real but conditional. Create, update, and delete work only on tables that have a primary key defined, and create operations must supply that key unless it is a generated identity column.
• Governance stays in Unity Catalog. The connector authenticates through Microsoft Entra ID and honors Unity Catalog’s fine-grained permissions, so the app only ever returns data the signed-in user is already allowed to see.
• It is a premium connector, and that is a licensing event. One premium connector makes the whole app premium, so every user needs a Power Apps Premium license at $20 per user per month ($12 at 2,000-plus seats).
• It is not everywhere. The connector is unavailable in GCC, GCC High, DoD, and the China cloud operated by 21Vianet — a hard stop for regulated and sovereign tenants.

The short answer: when to move off SharePoint lists to Databricks

Do not swap a working list for Databricks on principle. Make the move when you can name the specific limit you are hitting and accept the licensing delta it creates. These are the triggers that justify it:

• Scale: your list is past — or heading past — the 5,000-item view threshold, and delegation warnings are returning incomplete data.
• Single source of truth: the data already lives in your lakehouse, and the list is a stale copy someone re-exports by hand.
• Governance: the data needs row filters, column masks, lineage, and audit that a SharePoint list cannot enforce.
• Real-time accuracy: the app must read current data computed in Databricks, not last night’s extract.

If none of those apply, a well-indexed list with delegable queries is still the cheaper, simpler choice. The connector earns its licensing cost only when the list has become the bottleneck.

Why do SharePoint lists break down as a Power Apps data source?

The problem is almost never storage. A SharePoint list can hold up to 30 million items; what breaks is how much it can return at once. SharePoint enforces a 5,000-item List View Threshold to protect the backend database from large table locks, so unindexed queries over a big list throw the familiar “exceeds the list view threshold” error.

Power Apps adds a second, separate ceiling. By default it retrieves only 500 rows from a data source, configurable to a maximum of 2,000, and any non-delegable function runs only against that partial set. The result is the most dangerous kind of bug: on a small list the app returns correct answers, then silently returns truncated, wrong results once the list grows past the limit — months after you shipped. Indexing and delegable queries push this further, but they do not remove the architectural ceiling. When an operations app genuinely needs hundreds of thousands of governed rows with live writes, a list is the wrong backend.

What is the Databricks connector for Power Platform?

The Databricks connector is a first-party, certified connector that lets Power Platform build on lakehouse data directly, with no custom API plumbing and no copied data. Per Databricks’ launch announcement, every interaction happens in real time against Databricks tables, authentication runs through Microsoft Entra ID, and Unity Catalog’s access controls apply without a second security model to maintain. It reached general availability on June 23, 2026, after a public preview that began in June 2025.

It works across three surfaces, and each does a different job, per Microsoft’s connector reference.

The three Power Platform surfaces compared

Power Apps

• What it does: Builds canvas apps that read from and write to Databricks tables directly.
• Best for: Replacing a SharePoint-list-backed app with a governed lakehouse backend.
• Key limit: Canvas apps must connect directly; they cannot use Dataverse virtual tables.

Power Automate

• What it does: Exposes the Databricks Statement Execution API and Jobs API as actions — run SQL, poll status, fetch results by chunk, and trigger or cancel Jobs.
• Best for: Bulk writes, scheduled syncs, and running existing Databricks Jobs from a flow.
• Key limit: Deterministic, API-driven work — not a substitute for app-side interactivity.

Copilot Studio

• What it does: Uses Databricks tables as a knowledge source or connects Genie Agents as tools for natural-language answers.
• Best for: Conversational analytics over governed data, covered in our guide on connecting Databricks to Copilot Studio.
• Key limit: The Genie-in-Copilot-Studio path carries its own preview requirements.

The connector does not modernize your app by itself — it moves the bottleneck from the list to your licensing, your governance model, and the one primary key your table was never designed to have.

If you want that move done right — the connection wired through Entra ID, Unity Catalog permissions proven against real users, and the licensing modeled before you roll out — BabyBots runs fixed-fee Power Platform data-modernization assessments that map your SharePoint-to-lakehouse path in a single working session, so you ship a governed app instead of a second data silo.

Can Power Apps write back to Databricks?

Yes, with one firm condition. The connector supports create, update, and delete operations, but only for tables that have a primary key defined, and a create operation must always specify that primary key. If the table uses a generated identity column, Databricks produces the key on the server during row creation and you cannot set it manually. This single requirement is behind most “I can read but Patch throws an error” reports from the field — the table simply had no primary key.

Two more practical rules shape the write design. First, canvas apps can only write by connecting to Databricks directly; they cannot write through Dataverse virtual tables, and a virtual table itself requires a primary key, so a plain view cannot be a virtual table while a materialized view can. Second, for bulk create, update, or delete in response to app input, Databricks recommends offloading the work to a Power Automate flow triggered by the app rather than looping writes in the app itself. That keeps the interactive layer responsive and pushes batch work to the Statement Execution API.

What does the Databricks connector cost to license?

The connector is classed as a premium connector across Power Apps, Power Automate, and Copilot Studio. That classification is the cost, because the rule is unforgiving: the moment an app uses a single premium connector, the whole app becomes premium and every user who runs it needs a paid Power Apps license. A Microsoft 365 seat that covered a SharePoint-list app does not cover a Databricks-backed one.

Licensing paths for a Databricks-backed app

Power Apps Premium (per user)

• Price: $20 per user per month, dropping to $12 at 2,000-plus seats, paid yearly.
• Best for: Broad, business-critical rollouts where users open the app regularly.

Power Apps pay-as-you-go

• Price: about $10 per active user per app per month, billed through Azure.
• Best for: Pilots, seasonal users, or external vendors where only some users open the app in a given month.

Power Automate for the write and sync layer

• Price: included when the flow runs “within app context” off the Power Apps trigger; otherwise Power Automate Premium at $15 per user per month.
• Best for: Batch writes and scheduled Databricks Jobs invoked from the app.

Budget this before you build, not at the next true-up. Microsoft has also set licensing enforcement for Power Apps to begin in February 2027, so grandfathered gaps will close. If part of your automation runs outside the app context, read our breakdown of where that line sits in Copilot Studio agent flows vs. Power Automate.

How does the connector keep data governed?

Governance is the connector’s strongest argument over a list, because it inherits controls you already run instead of inventing new ones. Authentication is Microsoft Entra ID, using either user-based OAuth when Power Platform and Databricks share a tenant or a service principal, which is required when they sit in different tenants. Once connected, queries execute under Unity Catalog, so object privileges, row filters, and column masks decide every result, and the app cannot surface data the signed-in user could not already query. Activity is captured through Databricks Query History for auditing.

Setup requirements are modest but specific: an Entra ID account, a premium Power Apps license, a Databricks account, and Databricks SQL access with at least CAN USE permission on a SQL warehouse, per Microsoft’s connection setup guide. For workspaces behind a virtual network, you connect through virtual network peering to a private endpoint or enable a hybrid front-end private link protected by a workspace IP access list.

What limits do you need to plan around?

Three constraints decide whether this connector is viable for your tenant, and all three are better discovered now than mid-build.

• Cloud availability: the connector is not available in US Government (GCC), GCC High, US Department of Defense (DoD), or the China cloud operated by 21Vianet. Sovereign and regulated tenants should stop here and plan a different pattern.
• Primary keys: no primary key means no write-back, so tables destined for app writes need to be designed or remodeled with one before go-live.
• Compute: a Databricks SQL warehouse backs the queries, and serverless SQL is the practical default so the warehouse is available on demand rather than waiting on a classic cluster to spin up.

SharePoint list versus the Databricks connector

SharePoint list

• Serves at scale: Constrained by the 5,000-item view threshold and 500–2,000 row delegation limit.
• Governance: List and site permissions only; no row or column security.
• Licensing: Covered by most Microsoft 365 seats using standard connectors.
• Best for: Small-to-mid lists with simple access needs.

Databricks connector

• Serves at scale: Real-time queries over lakehouse tables, no list threshold.
• Governance: Unity Catalog row filters, column masks, lineage, and audit.
• Licensing: Premium connector — every user needs a paid Power Apps license.
• Best for: Large, governed, single-source-of-truth data with live writes.

Frequently Asked Questions

Is the Databricks connector for Power Platform generally available?

Yes. The connector reached general availability on June 23, 2026, after a public preview that began in June 2025. It supports Power Apps, Power Automate, and Copilot Studio, and it maintains Databricks governance controls through Unity Catalog. Earlier preview-era reports of broken write-back are generally resolved once the target table has a primary key.

Do I need a premium license to use it?

Yes. The Databricks connector is a premium connector, which makes any app that uses it a premium app, so every user needs a Power Apps Premium license at $20 per user per month ($12 at 2,000-plus seats) or a pay-as-you-go entitlement. A Microsoft 365 seat that covered a standard-connector list app will not cover a Databricks-backed one.

Why can’t my Power App write back to Databricks?

Almost always because the target table has no primary key. The connector supports create, update, and delete only on tables with a primary key defined, and create operations must supply that key unless it is a generated identity column. Add or remodel a primary key and write operations work.

Can I use the connector in a GCC or GCC High tenant?

No. The connector is unavailable in US Government (GCC), GCC High, US Department of Defense (DoD), and the China cloud operated by 21Vianet. Regulated and sovereign tenants need a different integration pattern, such as an API facade or an ETL path into a store the app can reach.

Should I replace every SharePoint list with Databricks?

No. Keep lists for small-to-mid datasets with simple access needs, where a well-indexed list and delegable queries perform fine and cost nothing extra. Move to Databricks when you have named a real limit — scale past the view threshold, governance the list cannot enforce, or a single-source-of-truth requirement — and accepted the premium licensing that comes with it.

How does Power Automate fit into a Databricks-backed app?

Power Automate exposes the Databricks Statement Execution API and Jobs API as actions, so a flow can run SQL, fetch large result sets by chunk, and trigger existing Databricks Jobs. Databricks recommends using a Power Automate flow triggered by the app for bulk create, update, or delete, which keeps the interactive layer responsive while batch writes run through the API.

Where this is heading

The low-code backend question is shifting from “which list” to “which governed table.” As Unity Catalog becomes the control plane for enterprise data and Power Platform standardizes on Entra-authenticated, premium connectors, the SharePoint list stops being the default home for operational app data and becomes what it was always best at — lightweight, small-scale collaboration. For teams already invested in a lakehouse, the practical implication is that the app layer and the data layer finally share one governance model instead of two. The decision in front of you is less about technology than about sequencing: fix the primary keys, model the licensing, and prove the governance before the rollout, not after.

Modernize your SharePoint-backed app the right way

If you have a Power App straining against a SharePoint list and a lakehouse already holding the real data, book a BabyBots Power Platform data-modernization assessment. In a single working session we map your move from list to Databricks — the connection and identity model, the Unity Catalog permissions, the primary-key and write-back design, and the licensing math — so you leave with a costed, governed plan rather than a stalled migration.

Sources

• Databricks Updates — Databricks Connector for Power Platform is generally available (June 23, 2026)
• Microsoft Learn — Databricks connector reference (classes, regions, limitations)
• Microsoft Learn — Use Databricks data on Microsoft Power Platform (read, write, Dataverse virtual tables)
• Microsoft Learn — Create a Databricks connection on Microsoft Power Platform (requirements, auth, networking)
• Databricks Blog — Introducing the Azure Databricks Power Platform Connector
• Microsoft Support — List View Threshold for large lists and libraries
• Microsoft — Power Apps licensing and pricing (2026)
• Microsoft Learn — Power Apps licensing FAQs (premium connector triggers, February 2027 enforcement)
• Microsoft Negotiations — Power Platform premium connectors licensing (2026)