Power Platform architecture

Dataverse vs Azure SQL: deciding who owns the data layer under your Power Apps

By Edward Pinela — Microsoft-certified consultant · September 25, 2026

Dataverse vs Azure SQL for Power Apps is a later decision than the one most teams meet first. If you are still weighing a free SharePoint list against Dataverse — list thresholds, delegation limits and the jump to premium licensing — start with Dataverse vs SharePoint lists for Power Apps instead. This page assumes you are past that point: the app needs premium licensing either way, because the SQL Server connector is a premium connector too. So the argument is not the cost of entry. It is ownership — take the business layer Dataverse ships with (security roles, auditing, model-driven apps), or run a SQL backend your own team engineers, secures and operates.

Why licensing stops being the tiebreaker

At the list stage, licensing decides a lot: a list-backed app on standard connectors runs on rights most Microsoft 365 users already have, and Dataverse does not. Once the requirement is “a proper database”, that asymmetry disappears. A canvas app talking to Azure SQL through the SQL Server connector and a canvas app on Dataverse both put their users on premium Power Apps licensing, so a comparison framed as “which one is cheaper to license” usually compares two versions of the same line item.

What does differ is who holds the rest of the bill and who carries the work. Dataverse storage is tenant capacity that sits with your Power Platform licensing and is watched by whoever administers the Power Platform. An Azure SQL database is billed on an Azure subscription at a service tier somebody chose, and it is watched — or not — by whoever owns that subscription. Neither is inherently cheaper. The useful question is which budget and which team you want the running cost to land on, and whether that team knows it is theirs.

What the Dataverse business layer does without being built

Dataverse is not just a place to put rows; it is a set of platform services wrapped around the rows. Microsoft’s introduction to Microsoft Dataverse (opens in new tab) describes tables with relationships, business rules and logic, and security applied at the data layer, so every app, flow and report that touches a table inherits the same behaviour. The value is less any one feature than the fact that none of them has to be designed, coded or maintained by you.

The security model is the clearest example. Microsoft’s security concepts in Microsoft Dataverse (opens in new tab) cover security roles, business units, owner and access teams, record sharing and column-level security — the machinery for “each region sees its own records” and “only HR sees the salary column”, configured rather than written. Auditing of record changes is a setting you switch on for the tables and columns that need it. Deployment between development, test and production environments travels in Power Apps solutions (opens in new tab), alongside the apps and flows that depend on the tables.

And there is one capability that exists only here. Microsoft’s model-driven apps overview (opens in new tab) states that a model-driven app needs a data model housed in Dataverse. If the process is record-dense and people move between related records all day, that generated interface — views, forms, related-record navigation, dashboards — is often most of the reason to choose Dataverse. Whether your process wants that shape or a purpose-built screen is its own decision, covered in canvas apps vs model-driven apps.

What a SQL backend gives you, and what it asks back

Azure SQL is a full relational database engine, and a canvas app is simply one client of it. That is its strength. You get the schema exactly as you design it, T-SQL views and stored procedures for logic that belongs next to the data, indexing under your control, and a database that reporting tools, integrations and other line-of-business systems can read and write directly without going through the Power Platform. If the data already lives in SQL, or several systems share it, putting a Power App in front of it is usually less disruptive than moving it.

The same freedom is the bill. Azure SQL Database is a managed service, so Microsoft runs the engine and the infrastructure underneath it, but everything above the engine is yours: the schema and its migrations, indexes and query tuning, how users authenticate, what each of them may read, whether changes are audited, how long backups are retained, and which service tier the database runs on as usage grows. None of that is exotic work for a team with database skills. It is real work for a team without them, and it does not stop after go-live.

Security deserves a specific warning. Dataverse security roles do not follow the data out of Dataverse, so on a SQL backend row and column access has to be enforced in the database — permissions, views, procedures, and a connection where each user signs in with their own Microsoft Entra ID identity rather than a single shared SQL login. An app that merely hides rows on screen is showing a filtered view of data its connection can still reach. This is the single most common gap we find when reviewing SQL-backed Power Apps.

Query behaviour: closer than the list comparison

Delegation — Power Apps pushing a query to the data source instead of pulling rows to the device — is the headline issue when leaving SharePoint lists. Between Dataverse and SQL it matters less, because both are delegable data sources with broad coverage. Microsoft’s guide to delegation in a canvas app (opens in new tab) still applies to both: specific functions and column types can fall outside what a source delegates, and a non-delegable query quietly returns partial results. The practical difference is that on SQL you can move a hard query into a view or stored procedure, and on Dataverse you shape it with the table design, views and relationships the platform provides.

The two backends side by side

This is the checklist we walk through when both options are genuinely on the table. It is about ownership and capability, not price — the licence line is the same on both sides, so it is not a row.

Reading your own requirements

Most of these calls resolve once each requirement is written as a sentence. These are the ones that tip it in practice.

You do not always have to pick only one

Hybrid designs are common and often correct. A Dataverse app can keep the operational records — the part that needs roles, auditing and a model-driven interface — while reference or historical data stays in SQL where other systems maintain it. Dataverse virtual tables can surface external rows inside Dataverse without copying them, but they do not carry every capability of a native table, so check Microsoft’s documented limitations against the specific requirement before designing around them. Going the other way, Dataverse data can be exported to an analytics store for reporting rather than queried live by a SQL-based tool.

What does not work well is a split nobody wrote down: half the logic in Dataverse business rules, half in SQL triggers, and a canvas app stitching them together. If a hybrid is the answer, name which system is the source of truth for each entity and who owns each side.

How we make the call on a fixed-fee build

On a scoped engagement the backend is settled in the design conversation, before anyone opens a screen. We list the entities, who may see which rows and columns, what must be audited, which other systems touch the data, and — the question that decides more of these than any feature — who in your organisation will own the backend once we hand it over. Where Dataverse wins, the model, roles and solution pipeline are designed properly as part of Microsoft Dataverse consulting services. Where SQL wins, the database, its security and its Azure footprint are scoped with the same care our Microsoft Azure consulting work applies to any other workload.

Either way, the reasoning is written into the scope you approve before the fee is agreed. Builds are delivered by senior US-based engineers in a typical two to four weeks, with 30 days of hypercare after go-live, and everything lives in your own tenant and subscription. Describe the app and the data behind it and we will tell you which backend fits, and who should own it.