When I first learned that SQL Server databases were coming to Fabric, I wasn’t entirely sure how and why we would use it. Now that I’ve had a chance to use SQL Database in Fabric, I wanted to share some of my experience and thoughts about where and how it makes sense to use it. I thought: Fabric is an analytics platform, and we primarily store data in a Lakehouse or warehouse to prep it up for reporting and analysis with Power BI. Why would I want to store data in a SQL Server database in the Fabric SaaS environment? I’ve since implemented “SQL Database for Fabric” (aka “Fabric SQL Database”) in several projects and I’m just blown away by how fast and simple it is to use. In this post, I will dig into the cost and performance and use cases where this option makes the most sense compared to other hosted implementations of the SQL Server database engine.
I grew up with SQL Server and have installed and used the past 14 versions of the product since version 6.0, 6.5, 2000 through the current version 2025. Back in the day, it would take about 20 minutes to install SQL Server 6.0 from a CD-ROM and another couple of hours to configure your first database. While writing this, I provisioned a new SQL database in my Fabric environment in 18 seconds. Everything in Fabric just connects with no firewall rules or complicated connections. I can connect and use SSMS or the built-in web interface to create queries, indexes, views, stored procs, UDFs – all the SQL Server stuff that I know and love.
How about performance compared to the rest of Fabric? We’ve been using Fabric since it was in early preview around 2022. Moving data through lakehouses with Spark notebooks is fast and efficient but not suited for highly transactional operations, normalized tables with relational constraints. Fabric warehouse (like its Azure Data warehouse predecessor) is fast for a lot of reads at scale but not for transactional inserts and updates. It’s engineered to be a high-performing data warehouse and not a transactional SQL database. Enter SQL Database for Fabric. It’s SQL Server in all its glory, but without all the configuration and tweaking. How does this new flavor of SQL database compare to the rest of the SQL database family?
Cost Comparison
Here’s the question I get most: what does a SQL database in Fabric actually cost, and how does it compare to the alternatives? The short answer is that it doesn’t bill like anything else. Fabric doesn’t charge you per core or per database — it draws from a shared pool of Capacity Units (CUs) that your capacity already provides. Let me unpack what that means for your bill.
And notice how much simpler the decision is to begin with. Before you can even price a traditional Azure SQL Database, you have to choose: a purchasing model (DTU or vCore), then a service tier — Basic, Standard or Premium under DTU, or General Purpose, Business Critical or Hyperscale under vCore — then provisioned or serverless compute, then a single database or an elastic pool. That’s six service tiers across two purchasing models before you size a single vCore. Fabric collapses all of that into one choice: create the database on the capacity you already have.
How is it “Free”?
A SQL database in Fabric doesn’t come with its own price tag. It runs on the capacity you’re already paying for — the same CUs that feed Power BI, pipelines, and everything else in the workspace. If you already own a capacity, spinning up a database doesn’t add a new line item; it consumes headroom you’ve already bought. That’s why it can feel free.
Perception Matters
But “no separate bill” isn’t the same as free. The database still consumes shared CUs, and — the part that trips people up — it keeps consuming for a while after your query finishes. Once you understand that behavior, the usage charts stop being mysterious.
PAYG and Reserve pricing
You buy the capacity itself either pay-as-you-go or on a reservation. A one-year reserve runs roughly 37% below pay-as-you-go — an F64, for example, is about $8,388/month PAYG versus roughly $5,285 reserved. The chart below compares a Fabric reserve against an equivalent Azure SQL database across the F-SKU range.
Consumption and capacity units
You don’t buy cores for a Fabric SQL database. It draws from your capacity’s CU pool when it needs compute, and the conversion is fixed:
1 Capacity Unit = 0.383 database vCores
1 database vCore = 2.611 Capacity Units
So an F64’s 64 CUs work out to about 24.5 database vCores — if SQL were the only thing using the capacity. In practice it shares that pool with Power BI and everything else. Because the conversion is fixed, you can line up each F-SKU against the Azure SQL size that delivers roughly the same compute:
| Fabric SKU | CUs | ≈ SQL vCores | Nearest Azure SQL GP size |
|---|---|---|---|
| F2 | 2 | 0.8 | 2 vCore (or serverless) |
| F4 | 4 | 1.5 | 2 vCore |
| F8 | 8 | 3.1 | 4 vCore |
| F16 | 16 | 6.1 | 6 vCore |
| F32 | 32 | 12.3 | 12 vCore |
| F64 | 64 | 24.5 | 24 vCore |
| F128 | 128 | 49.0 | 40 vCore |
| F256 | 256 | 98.1 | 80 vCore |
Billing increments
Here’s the nuance that surprises everyone: CU usage doesn’t stop the instant your query finishes. While the database is active it autoscales to the work, and a minimum of 2 GB of memory stays allocated the whole time it’s online. After the last request it stays online for about 15 minutes so the next query doesn’t pay a cold-start penalty — then compute is released and compute billing drops to zero. The upshot: a two-minute burst of queries can bill about 17 minutes of compute.
| Time | What happens | What is counted |
|---|---|---|
| Minute 0–2 | Queries are running. | Compute is active and scales to the workload. |
| Minute 2–17 | No new query arrives, but the database stays online. | Online CPU and memory — including the 2 GB minimum — can still consume CUs. |
| After minute 17 | The database is still inactive. | Compute is released; compute billing is zero (storage still billed). |
Active workload + online window = the compute usage you actually observe
The database autoscales up to 32 vCores — and 32 × 2.611 = 83.6 CUs, more than an entire F32 (32 CUs ≈ 12.26 vCores) can supply, about 261% of it. That’s why the maximum-vCore setting matters: it caps how much of the shared pool one database can pull. Read actual consumption in the Microsoft Fabric Capacity Metrics app rather than guessing from query duration, and keep it predictable by batching related work and setting a sensible max-vCore cap.
Storage and Size
Storage is billed continuously, whether the database is online or asleep. A Fabric SQL database holds up to 4 TB, with tempdb up to 1 TB, and automatic backups are free up to 100% of the database size. And because the data is mirrored into OneLake automatically, it’s immediately available for analytics without building a separate pipeline.
Use cases for SQL Database in Fabric
Most of my use cases lately have been metadata and log storage for data engineering orchestrations. SQL Database in Fabric is an ideal choice for this scenario for its speed and ease of use. Prior to its availability, we had to either use an Azure SQL database, lakehouse or warehouse to store information for a metadata-drive ETL framework. Lakehouse and warehouses are great for read-only reporting but are not performant for frequent inserts and updates.
It’s a great storage option for fast Translytical Task flows and for demo data sets. With Rayfin Fabric apps, it is becoming an attractive option for moderate scale applications running alongside analytical reports and dashboard solutions.
Small-to-midsize operational databases are a good fit — anywhere from a few gigabytes up to the low hundreds of GB, comfortably under the 4 TB ceiling. This is the sweet spot: application backends, line-of-business app databases, operational data stores, configuration/metadata stores, and workflow or state tables that also feed Power BI. The storage footprint stays modest, so the always-on storage charge is small, and the auto-mirroring into OneLake means that operational data is immediately available for analytics without building a separate pipeline. If you already own Fabric capacity for Power BI, a database in this size range rides on capacity you’re paying for anyway.
Anything that is — or will grow — beyond a few terabytes is likely a better fit for Azure SQL or SQL Server running in a VM or on-prem. There’s no Hyperscale-style escape hatch here (Azure SQL Hyperscale reaches 100 TB; a SQL Server VM is limited only by its disks), so a database you expect to cross 4 TB is the wrong shape for Fabric SQL from day one. Large data-warehouse or big-analytics storage is also a poor fit conceptually — that belongs in a Fabric Warehouse or Lakehouse over OneLake, not in the operational SQL engine. Two subtler storage-related misfits: tempdb-heavy workloads that need more than 1 TB of temp space, and large-but-idle databases — because storage bills 24/7 regardless of whether compute is paused, a big database that’s queried only occasionally pays a continuous storage floor with little compute offsetting it, which is poor cost efficiency compared to a VM or a right-sized Azure SQL tier.
