From Dev to Dashboard – Azure SQL vs Fabric SQL in Practice

Description

Should you run your analytics workloads in Azure SQL or Fabric SQL? This session compares architecture, performance, cost, and integration. Learn where each platform shines — from dev to operational reporting — and get a decision framework to choose the right SQL engine for your scenario.

Key Takeaways

• General Purpose (serverless / provisioned) – Gen 5 (80/128 vCores, 240/625GB RAM, 4TB), FSv2, DC
• Hyperscale (serverless / provisioned) – Gen 5 (80 vCores, 240GB RAM)
• Business Critical – Gen 5 (128 vCores, 625GB RAM, 4 TB), DC
• Read-only Replica: 1 (SQL analytics endpoint)
• 150 Databases per workspace
• Availability zone support
• BCDR → Phase 2: Disaster failover → Not defined for “Fabric SQL”

My Notes

Action Items

• [ ]

Resources & Links

Slides

From Dev to Dashboard Azure SQL vs Fabric SQL
in Practice
Matthias Nohl | b.telligent
March 18th, 2026
Your Speaker
Strategic Partner Manager &
Microsoft Community Lead @
b.telligent Deutschland GmbH
My Job
linkedin.com/in/matthiasnohl
Munich
My Hometown
Let‘s Connect
Agenda
Introduction
Architectures:
Azure SQL vs Fabric SQL
Features
• Security
• Governance
• Integration
• Development
Demo – Let‘s start the journey
Costs & Billing
Decision framework
01 - Introduction
The “Why”
Azure SQL
Fabric SQL
Databases
Includes: single databases, elastic pools, and database servers
Managed instances
Includes: single instances, instance pools
SQL virtual machines
Includes: 60+ available images combining SQL Server 2008-2019
and a variety of available OS and license types
The “Why” – Different Architecture Patterns
Basic BI
Workload
Basic web
application
Source: Basic Web Application - Azure Architecture Center | Microsoft Learn
02 - Architectures: Azure SQL vs Fabric SQL
Architecture - Facts First
Azure SQL
„Build applications using a fully managed SQL database with built-in performance and reliability.”
vCore-based:
• General Purpose (serverless / provisioned) – Gen 5 (80/128 vCores, 240/625GB RAM, 4TB), FSv2, DC
• Hyperscale (serverless / provisioned) – Gen 5 (80 vCores, 240GB RAM)
• Business Critical – Gen 5 (128 vCores, 625GB RAM, 4 TB), DC
DTU-based purchasing model:
• Basis
• Standard
• Premium
Source: What Is a Single Database? - Azure SQL Database | Microsoft Learn
Architecture - Facts First
Fabric SQL
„Build modern cloud apps that scale on an intelligent, fully
managed database.”
vCore-based:
• Up to 32 vCores
• 4 TB Storage
• 1,024 GB Tempdb
• 50 MB/s Lograte
• Read-only Replica: 1 (SQL analytics endpoint)
• 150 Databases per workspace
Source:
Limitations for SQL database - Microsoft Fabric | Microsoft Learn
Single database vCore resource limits - Azure SQL Database | Microsoft Learn
Architecture - Facts First
What do you get in Fabric?
Source: SQL Database in Fabric - What, Why, and How? - Data Mozart
Architecture - Facts First
Fabric SQL
SKU
Capacity Units (CU)
SQL database
vCores per second
F2
0.766
F4
1.532
F8
3.064
F16
6.128
F32
12.256
F64
24.512
F128
49.024
F256
98.048
F512
196.096
F1024
392.192
F2048
784.384
vCores to CUs Mapping
“1 Fabric capacity unit corresponds to
0.383 Database vCores, or,
1 Database vCore corresponds to 2.611
Fabric capacity unit.”
Source: Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
Architecture - Facts First
Deep-Dive? Reliability in Microsoft Fabric
• Availability zone support
• BCDR → Phase 2: Disaster failover → Not defined for “Fabric SQL”
• But: Experience-specific disaster recovery guidance
• “To protect against a regional failure, users of SQL databases can take proactive measures to periodically export their data and use the
exported data to recreate the database in a new workspace when needed.”
• SLA 99,9% Uptime
Maximum Available Minutes: The sum of all minutes that a given, individual Capacity has been instantiated during an Applicable Period
for a given tenant.
Downtime Minutes*: The total accumulated minutes in an Applicable Period for a given Capacity, after its creation, or before it is
deprovisioned when the Capacity is unable to be utilized in all applicable Fabric features listed below:
SQL Database
• "SQL Database" means any SQL database created in Microsoft Fabric workspace.
• Open Database: Open and view a SQL database in the service.
Source:
Reliability in Microsoft Fabric | Microsoft Learn
Microsoft Fabric disaster recovery experience specific guidance - Microsoft Fabric | Microsoft Learn
Licensing Documents
Architecture - Facts First
How does it work?
• SQL database in Fabric autoscales compute and provisions a minimum of 2 GB memory, billed as
compute while the database is online.
• After 15 minutes of inactivity, all compute resources including CPU and memory are released, and
the compute bill is zero.
Be careful: Scales means…Fabric F64 → 24.512 vCores Max
Source: Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
03 - Features
Security
Feature / Capability
Fabric SQL Database (SaaS)
Azure SQL Database (PaaS)
Always Encrypted
Not available
Available
Transparent Data Encryption (TDE)
Available (with CMK)
Available
Application Roles
Not available
Available
EXECUTE AS
Not available
Available (EXECUTE AS USER)
Authentication
Entra ID only; no SQL logins
Entra and SQL logins supported
Network Security
Private Links (tenant-level/workspace-level) for SQL Endpoint
Private Links, VNet integration
Source: Supported scenarios for workspace private links - Microsoft Fabric | Microsoft Learn
Governance
Feature / Capability
Fabric SQL Database (SaaS)
Azure SQL Database (PaaS)
Geo-Replication / Failover Groups
Not available
Available
Auditing
Audit logs to OneLake (preview)
Audit logs to Azure Monitor / Log Analytics
Compliance
ISO 27001/17/18, SOC 1/2/3, HIPAA (BAA)
ISO, SOC, HIPAA, PCI, FedRAMP, etc.
Backup & Restore
Automatic, 7-day retention (35 max), no geo or cross-workspace-restore
Automatic + manual restore, LTR, geo-restore
• Access Control

• Access via Fabric workspace roles (Admin, Member, Contributor, Viewer) and item-level permissions
• Native SQL permissions and database roles (“Manage SQL Security”) also supported
  • Data Classification & Labels
• Integration with Microsoft Purview
• Sensitivity labels and protection policies supported
  Integration
  Feature / Capability
  Fabric SQL Database (SaaS)
  Azure SQL Database (PaaS)
  Power BI Direct Lake
  Native support for real-time analytics without import
  Only via Import or DirectQuery
  Power BI Write Back
  via Translytical Task Flows (User Data Functions)
  Not available
  Spark / Notebooks / Real-Time Analytics
  Seamless integration via OneLake
  Requires separate services
  Vector Data Type & RAG Support
  Available (for AI/ML use cases)
  Available (for AI/ML use cases)
  GraphQL API Generation
  Available (auto-generated)
  Not available
  • SQL Analytics Endpoint
  • Read-only TDS endpoint for analytical workloads (MPP engine)
  • Cross-Database Queries
  • JOINs across Fabric SQL DBs, Warehouses, Lakehouses via 3-part naming
  • Data Virtualization (Ext. Files)
  • Query external files (Parquet, CSV, JSON) via OPENROWSET & External Tables through OneLake Shortcuts
  • Spark & Data Engineering
  Access SQL data via Delta (OneLake) or JDBC in notebooks & pipelines
  • Mirroring & Pipelines
  • Near real-time sync from external SQL sources (e.g., on-prem, Azure SQL MI) via CDC & pipelines
  Development
  Project Structure & Source Control
  •
  •
  Azure SQL: Uses SQL Database Projects (SSDT or VS Code) → builds a .dacpac. No built-in Git integration.
  Fabric SQL: Optional built-in Git integration at workspace level (Azure DevOps/GitHub). Changes can be committed or pulled directly via UI.
  Build & Validation (CI)
  •
  Both: Build SQL project to generate a .dacpac (via dotnet build or VS/VS Code).Validates syntax, object references, and target platform compatibility (Azure SQL or
  Fabric).
  Deployment (CD)
  •
  •
  Azure SQL: Deploy .dacpac via SqlPackage or Azure DevOps task (SqlAzureDacpacDeployment). Auth via SQL login or Entra (incl. service principal).
  Fabric SQL: Only Entra authentication (e.g., service principal with workspace access). Deployment via SqlPackage with Entra connection string and e.g. fabric-cicd
  Python tool
  (artefact)
  Configuration & Secrets
  •
  •
  Azure SQL: Connection strings, passwords, etc., managed via Azure Key Vault or pipeline secrets.
  Fabric SQL: Workspace-specific server names, Entra SPN credentials via Key Vault. No SQL logins supported.
  Testing
  •
  Both: tSQLt unit tests in Docker/local SQL Server/SQL MI; integration tests against Azure / Fabric SQL.
  Rollback
  •
  •
  Azure SQL: Point-in-time restore (7–35 days), DACPAC rollback possible.
  Fabric SQL: PITR (7 days), no overwrite – restore creates new DB. Rollback typically via re-deploying previous DACPAC.
  Environments
  •
  •
  Azure SQL: Separate servers/DBs per environment.
  Fabric SQL: Separate workspaces (Dev/Test/Prod), Git branch per workspace, deployment via merge + update
  Monitoring
  Built-in Metrics
  •
  •
  Azure SQL: Exposed via Azure Monitor: CPU, DTU/vCore usage, storage, sessions, etc.
  Fabric SQL: Capacity-level metrics via Fabric Capacity Metrics App; limited per-DB granularity
  Query Performance Insights
  •
  •
  Azure SQL: Query Store, DMVs, and Query Performance Insight in Azure Portal
  Fabric SQL: DMVs available; Performance Dashboard for SQL database
  Auditing
  •
  •
  Azure SQL: Full auditing to Azure Monitor, Log Analytics, Event Hub, or Storage
  Fabric SQL: SQL auditing in preview; logs to OneLake; limited configuration options
  Alerts & Diagnostics
  •
  •
  Azure SQL: Alerts via Azure Monitor; diagnostic settings configurable per DB
  Fabric SQL: Perfomance Dashboard supports Alerts (ongoing & pending); relies on capacity-level monitoring or external tools
  Telemetry Access
  •
  •
  Azure SQL: Rich telemetry via Azure Monitor, Application Insights, and Log Analytics
  Fabric SQL: Limited telemetry; some logs available via Fabric Admin APIs or audit preview
  Performance Tuning Insights
  •
  •
  Azure SQL: Automatic tuning recommendations, index suggestions, plan regression detection
  Fabric SQL: Auto-indexing enabled by default; no tuning dashboard yet
  Third-party Integration
  •
  •
  Azure SQL: Supported via Azure Monitor APIs, Log Analytics, and diagnostic logs
  Fabric SQL: Limited; APIs emerging, but not yet mature for full external observability
  Source: Monitor Performance Using DMVs - Azure SQL Database & SQL database in Microsoft Fabric | Microsoft Learn
  04 - Demo – Let‘s start the journey
  05 - Costs & Billing
  Costs & Billing
  • 𝐼𝑖 𝜖 0,1 : online indicator 𝐼𝑖 = 0 (inactivity ≥ 15min)
  • Constant 𝑘 : 2.611 - CU per Database vCore
  • ∆𝑡𝑖 : interval duration in seconds
  • 𝑣𝑖 : vCores used each second
  • 𝑚𝑖 : Memory (GB) used each second
  • Normalization 𝑟 = 3GB per vCore for comparing memory to CPU
  • Minimum online memory 𝑚𝑚𝑖𝑛 = 2GB
  Then the billed CU-seconds for interval 𝑖 are:
  0,
  𝐼𝑖 = 0
  𝑚𝑎𝑥 𝑚𝑖 , 𝑚𝑚𝑖𝑛
  𝐶𝑈𝑖 = ൞
  𝑘∆𝑡𝑖 𝑚𝑎𝑥 𝑣𝑖 ,
  𝑟
  ,
  𝐼𝑖 = 1
  Source: Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
  Costs Example
  Time Interval
  (min)
  00:00 – 0:05
  0:05 – 0:15
  0:15 – 0:30
  0:30 – 0:60
  vCores used each
  second
  Memory GB used each
  second
  Compute dimension billed
  CU Seconds Billed (Simple Explanation)
  vCores used
  Used 2 vCores for 300 seconds. CPU was higher than memory, so
  billing is based on vCore usage.
  Calculation: 2 × 300 × 2.611 = 1,567 CU seconds.
  Memory used
  Used 6 GB memory for 600 seconds. Memory exceeded CPU, so
  billing is based on memory usage. Memory-to-vCore ratio: 6 GB = 2
  vCores.
  Calculation: 2 × 600 × 2.611 = 3,133 CU seconds.
  Minimum memory allocated
  Minimum 2 GB memory is allocated to keep the database ready,
  even when idle. Memory-to-vCore ratio: 2 GB = 0.6666 vCore.
  Calculation: 0.6666 × 900 × 2.611 = 1,567 CU seconds.
  No compute billed after 15
  minutes of inactivity
  No activity for 15 minutes, so all compute, including CPU and
  memory, is released. Compute billing stops.
  Calculation: 0 CU seconds.
  Total Estimated CU seconds: 6,267 CU seconds
  Source: Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
  Cost Comparison
  Assumptions:
  • 1 month = 730 hours
  • Datacenter: US EAST, ZRS, Gen 5
  • DB Size: 100GB, 30GB Log, 100GB Backup Size
  • 12.256 vCores F32 approx. = 12 vCores Azure SQL
  n
  Service
  4.204,80 $
  5,76 $
  Azure SQL
  General Purpose
  Provisioned
  3.009,17 $
  4,12 $$/month $$/hour $
  2.501,33 $
  3,43 $
  2.262,70 $
  3,10 $
  5.018,00 $
  6,87 $
  2.080,00
  2,85
  Storage $
  5,20 $
  29,90 $
  32,50 $25,00SKU$/month $$/hour $
  Fabric SQL
  F32
  Azure SQL
  Azure SQL
  Business Critical
  Hyperscale
  Provisioned
  Standard Series + 1 Replica
  5.951,85 $
  3.200,20
  8,15 $
  4,38
  PAYG
  OneYear
  Reserved
  Source: Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
  06 - Decision framework
  The Choice is Yours!
  Use Azure SQL if:
  • Your workload is very small, highly variable or
  needs massive throughput
  • You need extensive DR/Backup retention
  • You require features not (yet) in Fabric
  • You need standalone database access patterns
  Use SQL Database in Fabric if:
  • Your app’s value is tied to real-time insights and
  you want to avoid complex ETL
  • Your app could leverage the “new stuff”
  (GraphQL, AI, etc.)
  • You need to serve both end-user applications
  and analytical workloads from the same data
  • You are building a new solution on Microsoft
  Fabric anyway
  Sound off.
  The mic is all yours.
  Influence the product roadmap.
  Join the Fabric User Panel
  Join the SQL User Panel
  Share your feedback directly with our
  Fabric product group and researchers.
  Influence our SQL roadmap and ensure
  it meets your real-life needs
  https://aka.ms/JoinFabricUserPanel
  https://aka.ms/JoinSQLUserPanel
  How was
  the session?
  Complete Session Surveys in
  for your chance to WIN
  PRIZES!