Dataverse vs Azure SQL: When to Use Which

Choose Microsoft Dataverse when the data belongs to a Power Platform or Dynamics 365 app and you want managed logic, security, and a metadata-driven schema you can stand up in days; choose Azure SQL Database when the data is the product — when you need full relational control, throughput and query patterns that exceed Dataverse's per-user request model, or a store that several non-Power-Platform systems will also hit. The two are not mutually exclusive, either: Dataverse virtual tables and elastic tables exist precisely to let one environment span both worlds without copying data around. The decision that matters is which system owns the source of truth for a given workload, and this guide gives you the criteria to answer that for your architecture rather than your resume.

Before the comparison, one framing point that saves most teams the wrong argument: Dataverse is not "a toy database" and Azure SQL is not "always more powerful in a way that matters to your app." Dataverse is a managed application data platform with its own relational engine, a role-based security model, business logic runtime, and a capacity-and-request metering model — it runs Dynamics 365 Sales, Customer Service, and Field Service at enterprise scale. Azure SQL Database is a fully featured Platform-as-a-Service relational database that hands you the T-SQL, indexing, and compute knobs. The right question is not "which database is better" but "which operating model fits this data's lifecycle, the apps that own it, and the team that will run it."

What Dataverse actually is (and what it isn't)

Dataverse is the cloud data platform that ships with the Power Platform. Data lives in tables (rows and columns), both a set of standard tables that cover common business scenarios and custom tables you define. Microsoft describes it as a place to "securely store and manage data that's used by business applications," where metadata and data are both stored in the cloud and access is governed by role-based security so users only see what you grant them.

What makes Dataverse more than a database is the application substrate layered on top of the storage engine:

• Business logic as a first-class runtime. Calculated columns, business rules, classic workflows, and business process flows enforce data quality and process behavior at the platform level, so the same rules apply regardless of which app or client touches the data.
• A metadata-driven schema. Relationships, data types, and choices are defined declaratively and consumed directly by model-driven Power Apps — you model data once and forms, views, and charts are generated from it.
• Native Dynamics 365 alignment. Dynamics 365 Sales, Customer Service, Field Service, and Human Resources all store their data in Dataverse, so apps you build there run against the same business data the first-party apps use, with no integration step.
• A single, governed API surface. Everything — Power Apps, Power Automate, Copilot Studio, custom clients, and the first-party apps — talks to Dataverse through the same web services (REST and SOAP), with a consistent identity, auditing, and security model.

What Dataverse is not: it is not a general-purpose SQL Server you can log into and DDL freely, and it is not a place where you tune query plans or attach any arbitrary workload. You interact through Dataverse APIs and the maker tooling, and your capacity and throughput are governed by the platform's metering rather than by compute you provision yourself. That trade — giving up low-level control in exchange for a managed, logic-rich application data service — is the whole premise, and it's the right trade for a large class of internal business apps.

What Azure SQL Database brings to the table

Azure SQL Database is Microsoft's managed SQL Server in the cloud — the same engine, exposed as a PaaS database where you control schema, indexing, query, and performance tuning. Under the vCore purchasing model you pick a service tier and a compute size on standard-series (Gen5) hardware:

• General Purpose gives you remote-SSD storage with either provisioned or serverless compute (serverless auto-scales compute and pauses on idle), with single-database max data sizes that scale into the multi-terabyte range.
• Business Critical adds locally attached SSDs and readable secondaries for low-latency, high-IOPS, and read-scale workloads.
• Full T-SQL fidelity. Stored procedures, triggers, indexed views, columnstore, in-memory OLTP, temporal tables, cross-database queries (within a server/elastic pool), and fine-grained index tuning are all available.
• Provisioned control over throughput. You scale compute and storage by sizing vCores and the data cap; there is no per-user daily request cap shaped by who logged in.

In short, Azure SQL gives you a database that is yours to operate: you design the model, own the performance, and pay for the compute and storage you allocate. Any system — a .NET service, a Java batch job, a BI tool, a Power App via a connector, a competing vendor's product — can connect to it with standard SQL tooling. That openness is its main advantage and, relative to a governed platform like Dataverse, also its main operational burden: you, not the platform, own schema migrations, backups strategy details, indexing, and security hardening at the database layer.

The decision drivers, side by side

Most "Dataverse vs Azure SQL" debates get stuck because teams compare feature checklists instead of operating models. The table below frames the six drivers that actually decide the architecture.

• **Primary home of the data** — Dataverse: Power Platform / Dynamics 365 apps · Azure SQL Database: Cross-system, data-first workloads
• **Throughput model** — Dataverse: Per-user, per-24-hour request entitlements + capacity pools · Azure SQL Database: Provisioned vCore compute; no per-user daily cap
• **Data model & consistency** — Dataverse: Standard tables (relational, strong) + elastic tables (Cosmos-backed, session consistency) · Azure SQL Database: Pure relational, strong consistency, full T-SQL
• **Logic & automation** — Dataverse: Business rules, workflows, plug-ins, business process flows in-platform · Azure SQL Database: Stored procedures, triggers, external app logic
• **Security model** — Dataverse: Role-based, environment-scoped, governed via DLP + Microsoft Entra · Azure SQL Database: DB-level users/roles, row-level security, firewall, Microsoft Entra
• **Cost shape** — Dataverse: Per-user licenses + per-request + capacity add-ons (database/file/log) · Azure SQL Database: Metered compute (vCore) + storage + backups
• **ALM & team skills** — Dataverse: Solutions, low-code makers + pro devs · Azure SQL Database: SQL Server, DBA, migrations, schema tooling

1. Where does the app live?

This is the single highest-weight driver. If the answer is "in Power Apps, Power Automate, Copilot Studio, or a Dynamics 365 first-party app," then Dataverse is the default and Azure SQL is the exception — because Dataverse is the data layer those tools are designed against. Model-driven apps are generated from Dataverse metadata; plug-ins, business rules, and business process flows run in the platform; security and auditing are inherited. Reaching out to Azure SQL from those tools means adding a connector, owning the mapping, and losing the in-platform logic for that data.

If the answer is "the data serves several systems and Power Platform is just one consumer," Azure SQL is the natural source of truth. A transactional database that a web storefront, a fulfillment service, and a data warehouse all read from should stay a database; forcing it through Dataverse to satisfy one Power App would make Dataverse a bottleneck and a replica rather than the owner.

2. Throughput and scale: request limits vs provisioned compute

This is where Dataverse's operating model becomes a hard constraint and Azure SQL's becomes a budget line. Dataverse meters usage through Power Platform request limits that are allocated per user per 24 hours: 40,000 requests per paid user license (Power Apps/Power Automate per user, and most Dynamics 365 first-premium apps), 6,000 per 24 hours for per-app plans, Microsoft 365-included use, and Dynamics 365 Team Member, and 250,000 per 24 hours for a Power Automate per-flow plan. Crucially, the official limits documentation counts all create/read/update/delete operations plus assign and share, including internal system requests needed to complete a transaction, plus plug-ins and classic workflows — not just user clicks. A single visible action can fan out into many counted requests.

Storage is metered separately across three pools — database, file, and log — with a default environment shipping around 3 GB each of database and file capacity and 1 GB of log capacity as included entitlement. Microsoft is explicit that there is "no technical limit on the size of a Dataverse environment" and that the published numbers are entitlement limits, not hard ceilings — but exceeding entitlement means buying more or cleaning up, and request ceilings shape how fast a given workload can run regardless of data size.

Azure SQL inverts this: there is no per-user daily request counter. You provision vCores and storage on General Purpose or Business Critical, and throughput scales with the compute you pay for, bounded by the documented IOPS and worker limits for your service-level objective. If your workload is a high-volume ingestion pipeline, a reporting job that scans millions of rows, or an integration that bursts unpredictably, Azure SQL gives you a clean, metered ceiling you can plan capacity against — whereas the same workload against Dataverse standard tables would be shaped by per-user request throttling and may need elastic tables (below) to run at all.

3. Data model and consistency: standard tables, elastic tables, and where Cosmos DB enters

Dataverse now offers two storage models, and understanding the split is essential to a correct architecture decision. Standard tables are the relational default: strong consistency, relationships, transactions across tables during plug-in execution, and complex joins. Elastic tables are powered by Azure Cosmos DB, share the same maker experience and APIs as standard tables, and are designed for very large, real-time volumes — Microsoft's own example is ingesting tens of millions of rows per hour, with horizontal auto-scaling, JSON columns for flexible schemas, and Time-to-Live for automatic data expiry.

That split is also a partial answer to "can Dataverse scale like Azure SQL?" For high-volume, semi-structured, or IoT-shaped data, elastic tables bring Cosmos DB scale into the governed Dataverse model — counted against your log capacity rather than the database pool. But the trade-offs are real and documented: elastic tables don't support multi-record transactions (a post-operation plug-in error won't roll back the created row), provide strong consistency only within a logical session, and don't support filtering on related-table columns in views and queries. Microsoft's guidance is explicit: use standard tables when you need strong consistency, relational modeling, and transactional integrity; use elastic tables for high-volume, flexible-schema workloads; and a single solution often combines both.

Azure SQL, by contrast, is one consistent relational model: ACID transactions, foreign keys, indexed views, and cross-table joins with no consistency caveats. If your workload is fundamentally relational and needs strong, cross-table transactional guarantees at scale, Azure SQL (or Dataverse standard tables at lower volume) is the fit — not elastic tables.

4. Security, compliance, and governance

Dataverse's security is application-shaped: environment-scoped role-based security where users see data only if granted access, layered with row-level field security, business-unit hierarchies, and Power Platform data-loss-prevention policies that govern which connectors can move data where. Microsoft Entra identity is the default, and the same model covers Power Apps, Power Automate, and Dynamics 365. This is genuinely productive for internal apps — you get a defensible governance posture almost for free.

Azure SQL's security is database-shaped: server- and database-level firewalls, database users and roles, row-level security, dynamic data masking, Always Encrypted, Microsoft Entra authentication, and full control over auditing and threat protection. It is more flexible but also more work: you design and operate the security model at the data layer, and every connecting system must be configured to respect it. For multi-system datasets where Power Platform is one of many clients, a database-layer model is often more consistent than trying to express the rules in Dataverse and then re-expressing them in every other consumer.

The practical rule: when the security boundary you care about is "who in my organization can do what in this app," Dataverse wins. When the boundary is "which systems and identities can read which rows of this dataset, uniformly," Azure SQL wins.

5. Cost model: entitlement vs metering

Dataverse's cost is mostly entitlement-shaped: per-user licenses (which carry the request allowances above), per-request capacity for high-volume automation, and add-on capacity for the three storage pools. You pay for seats and capacity, and the platform manages the compute behind it. This is economical for internal apps with a bounded number of users and predictable storage — the request and capacity pools are sized to typical business-app usage.

Azure SQL's cost is metered: you pay for vCore compute (provisioned, reserved, or serverless) plus storage and backups, continuously. It can be cheaper for high-volume, low-interaction workloads (a batch system with two heavy users) and dramatically more expensive if mis-sized. It also scales more transparently: doubling throughput usually means doubling a compute line item, not renegotiating per-user licensing.

A common mistake is comparing them on a "per-GB" basis. Dataverse's price is dominated by users and requests, not storage; Azure SQL's is dominated by compute, not storage. The honest cost comparison is total cost for a specific workload profile, including the integration and operational cost of bridging whichever system is not the natural home for the data.

6. Lifecycle, ALM, and the team you actually have

Dataverse applications move through Solutions — managed packages that carry tables, apps, flows, and logic between environments. The maker-first tooling means a business analyst can model tables and build apps without writing code, while pro developers extend with plug-ins and custom connectors. ALM is real but it is a Power-Platform ALM, with its own conventions for solutions, environment strategy, and deployment.

Azure SQL lives in a database-engineering ALM: schema migrations (DACFX/.dacpac, DbUp, Flyway, EF Core migrations), source-controlled DDL, index tuning, and a DBA or platform-engineering practice. If your organization already runs SQL Server on premises or in Azure, the skills, runbooks, and tooling transfer directly; if your team is Power Platform-native, that database-ALM muscle may not exist.

Pick the system your team can operate well over five years, not just the one that demos well in week one.

When Dataverse is the right call

Reach for Dataverse as the source of truth when most of these are true:

• The primary consumers are Power Apps (especially model-driven), Power Automate flows, Copilot Studio agents, or Dynamics 365 first-party apps.
• You want business rules, workflows, and process flows enforced at the platform level so every client behaves identically.
• Security is organization-shaped (who can do what) and you want Entra-integrated, environment-scoped governance for free.
• Data volumes and request rates fit the per-user/per-request entitlement model, or can be routed to elastic tables for high-volume tiers.
• The team is more comfortable with low-code/maker tooling than with SQL Server operations.

Typical winners: a custom CRM extension on top of Dynamics 365 Sales, an internal service-request app, a field-inspection app for technicians, and any case-management or approval workflow where the process is the product. In all of these, the data's value comes from the app and the logic layered on it — which is exactly what Dataverse is built to deliver.

When Azure SQL is the right call

Reach for Azure SQL Database as the source of truth when most of these are true:

• The dataset serves multiple systems and Power Platform is one consumer among several (a web app, a batch job, an analytics pipeline).
• Throughput or volume exceeds Dataverse's request/capacity model — large ingestion, heavy reporting scans, or bursty integration traffic that would burn request entitlements.
• The workload is fundamentally relational and demands full T-SQL control: complex joins, stored procedures, indexed views, cross-database queries, or strict ACID guarantees at scale.
• Your team already operates SQL Server and the ALM, monitoring, and DBA tooling are in place.
• The data must remain portable and tool-agnostic so it is not locked into the Power Platform metering model.

Typical winners: an e-commerce transactional database, a financial ledger, a telemetry or events store that other services query directly, and any shared operational dataset that a Power App merely surfaces rather than owns. If you ever need to connect non-Microsoft or data-warehouse tooling to the same data as your Power App, Azure SQL is usually the better primary home.

The hybrid most production solutions actually ship

The cleanest architectures rarely pick one system for everything — they decide, per workload, which system owns the source of truth and then bridge cleanly. Three mechanisms do most of the bridging, and knowing which to reach for is what separates a senior architect from someone who defaults to "copy the data."

Virtual tables — keep data in Azure SQL, surface it in Power Apps. A Dataverse virtual table is a custom table whose columns come from an external data source at runtime, with no data replication — Microsoft's own example is connecting straight to an Azure SQL Database. Dataverse ships virtual connector providers for SQL Server, SharePoint, and Fabric, plus an OData v4 provider, so the data stays owned and operated in Azure SQL while appearing to model-driven apps as if it lived in Dataverse. Use this when Azure SQL is the source of truth and the Power App only needs to read or lightly edit it; avoid it for high-throughput writes or heavy joins, because every query round-trips to the external system and you inherit its latency and throttling.

Elastic tables — keep high-volume data in Dataverse, but in the Cosmos-backed tier. When the data genuinely belongs to a Power Platform app but is too large or too bursty for standard tables, route it to elastic tables. You keep the governed, in-platform model and gain Cosmos DB scale, paying for it with session consistency and the loss of multi-record transactions. This is the right answer for IoT signal capture, large ephemeral marketing-coupon pools, or audit-scale event logs that still need to participate in a Dataverse solution.

Replicate selectively, and own the direction. When you must copy, choose the direction deliberately and accept the trade-offs. Pushing a sliver of Azure SQL into Dataverse (via Power Automate, Dataflows, or a custom integrator) is fine for a read-mostly operational view; pushing Dataverse into Azure SQL for analytics is the standard pattern (Azure Synapse Link / Fabric mirroring), because reporting and ML workloads want a SQL warehouse, not the request-metered Dataverse API. Never replicate bidirectionally without a real conflict-resolution strategy — that is where most "we'll just sync both" projects die.

The governing principle for hybrids: exactly one system owns each record's truth. Virtual tables make Azure SQL the owner while Dataverse presents; elastic tables make Dataverse the owner at Cosmos scale; replication is for read-optimized copies, not for shared-write ownership. State that ownership explicitly in your design doc and most of the rest of the architecture follows.

A practical decision checklist

Run a new workload through this before you commit:

1. List every consumer of the data. If >50% are Power Platform/Dynamics 365, lean Dataverse; if Power Platform is a minority, lean Azure SQL.
2. Estimate peak requests per active user per day. If it approaches the 40,000 (or 6,000) per-24-hour ceiling, Dataverse standard tables are the wrong fit — consider elastic tables or Azure SQL.
3. Classify the data model. Relational with strong cross-table transactions → standard tables or Azure SQL. High-volume, flexible-schema, time-decaying → elastic tables or Azure SQL.
4. Identify the security boundary. Organization/role-shaped → Dataverse. Dataset/system-shaped → Azure SQL.
5. Check the cost shape, honestly. Model total cost for your user count and volume, including integration — never compare on per-GB storage alone.
6. Confirm the team and ALM. Maker/Solutions culture favors Dataverse; SQL Server/DBA culture favors Azure SQL.
7. Name the source of truth. Write down, per table family, which system owns it and whether any bridge (virtual table, elastic table, replication) is read or write.

Common mistakes to avoid

• "Let's just use Azure SQL for everything because it's more powerful." You inherit every schema migration, indexing decision, and security hardening, and you forfeit the in-platform logic, security, and ALM that make Power Platform apps cheap to build and run. For a typical internal app, that is a net loss.
• "Let's just use Dataverse for everything because it's lower-code." High-volume ingestion and heavy relational analytics against standard tables will collide with request limits and the capacity model, and you will end up with a fragile sync layer anyway.
• Bidirectional sync with no conflict plan. Two systems both writing the same record without deterministic conflict resolution produces data drift that surfaces months later, usually in a report a CFO reads.
• Treating elastic tables as a drop-in for standard tables. The session consistency, no-multi-record-transactions, and no-related-table-filter trade-offs mean logic written for standard tables can silently misbehave on elastic tables. Decide the table type by workload, not by default.
• Comparing cost on storage alone. The dominant cost line is users/requests for Dataverse and compute for Azure SQL. A storage-GB comparison will steer you to the wrong system.

Bottom line

Dataverse and Azure SQL solve overlapping but distinct problems. Dataverse is an application data service optimized for Power Platform and Dynamics 365 apps, with managed logic, security, and a metering model that is brilliant for bounded internal workloads and constraining for high-volume, cross-system ones. Azure SQL is a general-purpose relational database optimized for control, throughput, and interoperability, with a cost and operational profile that rewards a team ready to run it. The architecture decision is not which is "better" — it is which system owns the truth for each workload, and whether you bridge with virtual tables (present external data), elastic tables (scale Dataverse), or read-only replication (feed a warehouse). Get that ownership right per dataset and the rest of the design follows. If your organization is mapping this out across a Dynamics 365 rollout or a broader Microsoft Dynamics 365 estate, a Dataverse platform primer paired with a clear data-ownership model is where the conversation should start — and expert system integration help is worth the spend when the boundary between governed platform and owned database is what your go-live depends on.