SQL database in Fabric is GA: when it beats Azure SQL Database, and when it does not

SQL database in Microsoft Fabric is now generally available. How it differs from Azure SQL Database, what automatic mirroring to OneLake gives you, and how capacity billing works.

Brian Bønk19 November 20255 min read

Microsoft Fabric SQL database Azure SQL OneLake

Microsoft used Ignite 2025 to announce general availability of Fabric databases, and with it SQL database in Microsoft Fabric. A year after the preview, you can now run an operational SQL database inside a Fabric workspace with production support, and have its data land in OneLake without building a single pipeline.

That makes a real choice out of something that was an experiment until now. Many teams already run Azure SQL Database next to Fabric, so the useful question is not "is it good?" but "where does it fit, and where does it not?"

What you actually get

SQL database in Fabric is a transactional database built on Azure SQL Database. It uses the same SQL Database Engine, so your T-SQL, your SSMS habits and your SQL projects carry over.

When you create one, Fabric gives you three things in the workspace:

The database itself, for OLTP workloads.
Automatic replication of the data into OneLake, converted to Parquet in an analytics-ready format.
A read-only SQL analytics endpoint on top of that replicated data.

The product is SaaS first. Automatic tuning with automatic index creation is on by default, scaling is automatic, and so is pause and resume. Authentication is Microsoft Entra only, and source control and deployment pipelines are built into the Fabric workspace.

Mirroring is the main reason to care

The feature that changes the architecture is the automatic mirroring to OneLake. With Azure SQL Database you can mirror into Fabric too, but you set it up yourself: authentication, network connectivity and the choice of tables.

In SQL database in Fabric, the documentation lists the differences clearly:

Mirroring starts automatically when the database is created.
It is always on and cannot be turned off.
All supported tables are mirrored, with no option to skip tables.
A point-in-time restore creates a new database and starts mirroring again automatically.

For a data team, this means the operational data is in Delta format in OneLake close to real time. Spark, notebooks, Power BI and cross-database T-SQL queries through the SQL analytics endpoint can all read it, and the analytical load does not hit the transactional database.

The flip side is control. If you need to keep certain tables out of OneLake, this is not the place for them. Think about that before you put sensitive data in it.

How the billing works

SQL database in Fabric does not have its own price list in the Azure SQL sense. It consumes capacity units (CUs) from the Fabric capacity of the workspace, shared with every other Fabric workload on that capacity.

The documented conversion is simple: 1 CU equals 0.383 database vCores, so an F64 capacity is equivalent to 24.512 SQL database vCores. Cost is compute plus storage. Compute follows vCores and memory used, and storage is billed continuously, also when compute is paused.

One detail is worth knowing. After activity stops, the database stays online for another 15 minutes to keep response times good. The documentation's example is two minutes of work in an hour, billed as 17 minutes of compute.

You follow usage in the Microsoft Fabric Capacity Metrics app, where SQL database shows up under the item kind SQLDbNative. Most operations are reported as interactive with five-minute smoothing.

Where Azure SQL Database still wins

The feature comparison on Microsoft Learn is the honest part of this story. Some things you may rely on today are not there in SQL database in Fabric:

No active geo-replication, failover groups or geo-restore.
No long-term backup retention. Automatic backups default to seven days of point-in-time restore.
No elastic pools, elastic jobs or elastic query.
No VNet or VNet service endpoints, and the connection policy is fixed to Default.
No SQL logins, no Always Encrypted and no ledger tables.
No change data capture.
Limits of up to 32 vCores and 4 TB of storage per database.

None of this is unusual for a young SaaS product. But if your application needs cross-region disaster recovery, strict network isolation or years of backups for compliance, Azure SQL Database is still the right home, and you can mirror it into Fabric when you need the data for analytics.

What this means for you

After two decades in data, I see three cases where SQL database in Fabric is a clear yes:

Small and medium operational apps owned by the data team, such as master data, mapping tables, budgets or manual input that today live in Excel or a forgotten SQL Server.
Reverse ETL and operational data stores, where curated data has to be served back to applications.
Teams that already pay for a Fabric capacity and want one place for both the app database and the analytics.

And three cases where I would wait or choose Azure SQL Database:

Customer-facing systems with demanding uptime, disaster recovery or network requirements.
Workloads that are large or spiky enough to compete with your Power BI and Spark jobs on a shared capacity.
Databases where you must decide table by table what leaves the database.

The capacity point deserves a proper test. A busy transactional database draws from the same CUs as your reports. Put a realistic workload on a test capacity, watch it in the Capacity Metrics app, and decide whether it needs its own capacity.

Takeaway

SQL database in Fabric is now a production option, and the automatic mirroring to OneLake is a real reason to choose it for the right workloads. It is not a replacement for Azure SQL Database across the board, and the feature comparison tells you exactly where the gaps are.

Which of your operational databases would you move into Fabric first, and which would you keep exactly where they are?

Sources

Enjoyed this? Get the next one by email

Occasional emails about Microsoft Fabric, SQL Server, Power BI and Synapse.