Data Engineer Application Developer Data Architect DBA — This page explains the SQL Database in Fabric experience, the new Database Hub, how operational data flows automatically into OneLake, and when to choose Fabric databases instead of a warehouse or lakehouse.
Fabric Databases
Transactional SQL workloads inside Microsoft Fabric — with analytics-ready data available in OneLake automatically.
What Is Fabric Databases?
SQL Database in Fabric is a fully managed relational database experience built directly into Microsoft Fabric. It extends Fabric beyond analytics-only patterns by bringing OLTP capability into the same platform where you already run lakehouses, warehouses, notebooks, semantic models, and Power BI reports.
The practical advantage is simple: operational applications and analytics can live in one governed environment. Instead of pushing transactional data into a separate analytics platform through custom pipelines, the platform keeps the data estate aligned from the start.
🗄️ SQL-native experience
Built on the SQL Server family of technology, the experience provides familiar relational modeling, transactions, and full T-SQL compatibility for developers and DBAs.
⚡ OLTP + analytics together
Run transactional workloads inside Fabric while making the same data available for analytics without setting up a separate ETL or mirroring pattern.
🌊 OneLake-connected by design
Data is automatically replicated into OneLake so Spark, Direct Lake, and other Fabric engines can use it almost immediately for downstream analytics.
🛡️ Shared governance model
The database lives in a Fabric workspace, which means the same security, governance, lifecycle, and collaboration patterns can extend across app data and analytic data.
The biggest value proposition is not just “SQL in Fabric.” It is the combination of transactional storage plus automatic analytic availability in OneLake. That makes SQL Database in Fabric especially compelling for operational reporting, near real-time dashboards, and app scenarios where business users also need governed self-service analytics.
SQL Database in Fabric
A transactional SQL database natively integrated into the Fabric experience.
What It Is
SQL Database in Fabric is a transactional relational database service managed inside a Fabric workspace. It is based on the Azure SQL Database engine, bringing proven SQL capabilities into a Fabric-native operating model.
For teams that already build on SQL Server or Azure SQL, this means a low-friction path to adopt Fabric without abandoning familiar tooling or rewriting business logic. Full T-SQL support, along with stored procedures, triggers, and views, allows many existing patterns to carry forward.
Key Characteristics
- Transactional by design: Suitable for application backends, line-of-business systems, and operational data stores that need inserts, updates, deletes, and concurrency control.
- Full T-SQL support: Use tables, constraints, indexes, views, stored procedures, and triggers with familiar SQL development practices.
- Automatic replication to OneLake: Data is made available for analytics without creating a separate mirroring project or ETL process.
- Fabric workspace integration: The database is managed with the same workspace-centric governance, security, and collaboration model as the rest of Fabric.
- Capacity-based economics: Consumption comes from Fabric capacity units instead of a separate Azure SQL bill for the database service.
- Analytics-ready operational data: Spark, Power BI, and other Fabric engines can work from the replicated OneLake representation.
Best fit: app backends
Use it when your application needs a relational system of record but you also want those same tables to feed reporting, semantic models, and data products.
Best fit: operational analytics
It is well-suited for scenarios where business teams need near real-time insight into order flow, inventory, support cases, bookings, or customer activity.
Best fit: SQL-first teams
If your developers and DBAs are strongest in SQL and want to stay in a T-SQL-centric workflow, this experience lowers the adoption barrier significantly.
SQL Database in Fabric is not a replacement for every analytics storage pattern. It is optimized for transactional workloads. Use it when your primary need is OLTP with analytic reuse — not as a substitute for a large-scale warehouse or Spark-oriented lakehouse.
Database Hub
A unified database management pane announced at FabCon 2026.
Database Hub, announced at FabCon 2026, brings multiple database types into a single management surface. Rather than hopping between admin portals and service-specific views, teams can manage operational databases in a more consolidated way.
The goal is to give DBAs, architects, and platform operators a common control plane for inventory, observability, governance, and guided optimization across different engines.
Databases It Brings Together
| Platform | Included in Database Hub | Typical Role |
|---|---|---|
| Fabric | SQL Database in Fabric | Transactional data inside the Fabric platform |
| Azure SQL | Azure SQL Database | Managed SQL workloads in Azure |
| NoSQL | Azure Cosmos DB | Globally distributed operational applications |
| PostgreSQL | Azure Database for PostgreSQL | Open-source relational workloads |
| MySQL | Azure Database for MySQL | Web apps and packaged applications |
| Hybrid | SQL Server via Azure Arc | On-premises or hybrid SQL estates |
Highlighted Capabilities
- Unified observability: A broader view of health, usage, and performance signals across heterogeneous database types.
- Delegated governance: A more consistent management pattern for teams that need separation of duties across app owners, data owners, and platform administrators.
- Agent-assisted operations: Copilot-powered insights can help surface tuning opportunities, explain issues, and streamline administration tasks.
- Database savings plans: Announced guidance points to cost optimization opportunities of up to 35% savings in eligible scenarios.
Database Hub is in preview. Expect the UI, supported scenarios, and management workflows to evolve as Microsoft expands the experience and aligns it across more services.
Autonomous Features
Built-in self-management capabilities that reduce the day-to-day operational burden.
One of the major benefits of modern managed database services is the shift from manual administration to autonomous optimization. SQL Database in Fabric inherits that direction by combining Fabric operations with mature SQL engine intelligence.
Self-tuning
Automatic index management and statistics updates help maintain performance without requiring constant DBA intervention for common tuning tasks.
Auto-scaling behavior
Compute can adjust within the allocated Fabric capacity model, helping workloads handle changing demand more gracefully than fixed-footprint database deployments.
Performance insights
Built-in diagnostics make it easier to understand expensive queries, workload hotspots, and concurrency pressure before users feel the impact.
Intelligent query processing
SQL engine improvements such as adaptive optimization features help queries perform better without extensive code changes.
Automatic backup
Backups and point-in-time restore capabilities reduce operational risk and simplify recovery planning for production applications.
Self-healing behavior
Automatic failover within the availability zone helps improve resiliency for critical transactional workloads.
Why This Matters for Fabric Teams
Fabric often brings together data engineering, BI, and platform teams that are not always staffed like a traditional dedicated DBA organization. Autonomous features help smaller teams support production-grade relational workloads while keeping operational overhead aligned with a SaaS platform model.
OneLake Integration
The defining capability: transactional data replicated into OneLake for zero-ETL analytics.
How the Data Flows
SQL Database in Fabric
↓
Automatic replication
↓
OneLake (Delta format)
↓
Spark / SQL analytics / KQL / Power BI Direct Lake
This flow is the core differentiator. In a traditional architecture, operational data lives in a database and analytics teams then build pipelines, CDC jobs, or batch exports to make it useful elsewhere. In Fabric, the platform can replicate the data into OneLake in Delta format, which means analytics services can consume it without a separate data movement project.
What This Enables
- Zero-ETL analytics: Query the same business data with Spark, KQL, or Power BI without building custom ingestion pipelines first.
- Direct Lake semantic models: Create BI models on top of replicated data in OneLake to support fast, low-latency analytics experiences.
- Near real-time reporting: Business users can analyze operational activity with fresher data than traditional nightly warehouse loads.
- Simpler architectures: Fewer moving parts means fewer jobs to monitor, fewer failures to troubleshoot, and less duplicated logic.
This is what separates SQL Database in Fabric from a standalone Azure SQL deployment. The value is not only the database engine — it is the native, automatic connection to OneLake and the wider Fabric analytics stack.
For developers
Your application can keep using a SQL transactional backend while analytics scenarios light up in Fabric with far less integration effort.
For data engineers
You can start transformations from replicated OneLake data instead of building a full ingestion landing zone just to copy operational records.
For BI teams
You can model near real-time operational datasets with Direct Lake patterns rather than relying solely on scheduled imports or DirectQuery against the source database.
Graph Database in Fabric
Native graph analytics for modeling and querying complex relationships — GA since FabCon 2026.
What Is It?
Graph Database in Fabric is a fully managed graph database experience that brings relationship-first data modeling and querying directly into the Fabric platform. It uses the GQL (Graph Query Language) standard — the SQL equivalent for graph data — allowing you to model entities as nodes and their connections as edges.
🔗 When Relationships Are the Data
Relational databases struggle when the primary analytical question is about connections — "Who knows whom?", "What caused what?", "What's the shortest path between X and Y?". Graph databases make these queries natural and performant.
- Supply chains — trace components through multi-tier supplier networks
- Customer networks — identify communities, influence paths, churn risk propagation
- Knowledge graphs — connect business concepts, documents, and metadata for AI grounding
- Fraud detection — discover hidden rings and suspicious connection patterns
- IT dependency mapping — understand service-to-service impact for incident response
⚙️ Key Capabilities
- GQL support — ISO-standard graph query language for pattern matching, path traversal, and graph algorithms
- OneLake integration — graph data is stored in OneLake and accessible alongside other Fabric items
- Scalable — handles enterprise-scale graphs with millions of nodes and edges
- Fabric-native security — workspace roles, OneLake security, and Entra authentication apply
- Visualization — built-in graph visualization for exploring relationships interactively
- Spark interop — query graph data from Spark notebooks for advanced analytics and ML
Graph vs. Relational — When to Choose
| Signal | Use Graph Database | Stay Relational |
|---|---|---|
| Query pattern | Traversal, shortest path, pattern matching | Aggregation, joins on known keys |
| Schema | Flexible, evolving relationships | Fixed schema, normalized tables |
| Data shape | Many-to-many, recursive, hierarchical | Flat, dimensional, tabular |
| Performance priority | Multi-hop relationship queries | Bulk analytical scans |
| Typical depth | 3+ levels of relationships | 1–2 JOIN levels |
Getting Started
- In your Fabric workspace, select + New → Graph Database
- Define your node labels (e.g., Customer, Product, Supplier) and edge types (e.g., PURCHASED, SUPPLIES, KNOWS)
- Load data from OneLake tables, CSV files, or via Spark notebooks
- Query with GQL:
GQL — Find shortest supply chain path
MATCH path = SHORTEST (supplier:Supplier)-[:SUPPLIES*]->(product:Product) WHERE product.name = 'Widget-X' RETURN path, length(path) AS hops - Visualize results with the built-in graph explorer or export to Power BI
Start with a well-defined use case where relationships are the primary analytical axis. Build your knowledge graph incrementally — begin with 2–3 node types and expand as you prove value. Combine with Fabric IQ ontology to give AI agents context about entity relationships.
When to Use What
Choose the right Fabric storage experience based on workload shape, language preference, and downstream analytics needs.
| Factor | SQL Database in Fabric | Fabric Data Warehouse | Fabric Lakehouse | Graph Database |
|---|---|---|---|---|
| Primary use case | OLTP / transactional | Analytics / OLAP | Data engineering / ML | Relationship analytics |
| Query language | Full T-SQL | T-SQL (subset) | Spark SQL / PySpark | GQL (Graph Query Language) |
| Data format | Relational (SQL) | Delta (columnar) | Delta / Parquet / CSV | Nodes & edges (graph) |
| Best for | App backends, APIs, transactions | BI queries, aggregations | Data science, ETL, streaming | Path traversal, pattern matching, networks |
| Indexing | Full (clustered, non-clustered) | None (columnar auto-optimization) | V-Order optimization | Graph-native (adjacency) |
| Concurrency | High (OLTP optimized) | Medium (analytics optimized) | Spark session-based | Medium (traversal optimized) |
| OneLake integration | Automatic replication | Native | Native | Native |
| Direct Lake support | Via replicated data | Native | Native | Via export to Delta |
| T-SQL compatibility | Full | Subset (no stored procs) | Limited (SQL endpoint) | N/A (uses GQL) |
| Capacity consumption | CU-based | CU-based | CU-based | CU-based |
Decision Guidance
Choose SQL Database
Select SQL Database in Fabric when you are building applications on Fabric, need full T-SQL compatibility, support OLTP patterns, and want zero-ETL analytics on transactional data.
Choose Data Warehouse
Select Fabric Data Warehouse when analytics and BI are the primary outcome, your team prefers T-SQL, and you do not need the behaviors of a full transactional engine.
Choose Lakehouse
Select Fabric Lakehouse when your workload is Spark-first, data engineering heavy, machine learning oriented, or requires flexible handling of varied file types and large-scale transformations.
Choose Graph Database
Select Graph Database when your primary questions are about relationships, paths, and patterns — supply chain tracing, fraud rings, customer networks, or knowledge graphs for AI grounding.
If your first question is “How will the app write transactions?”, start with SQL Database. If your first question is “How will analysts query curated facts and dimensions?”, start with Warehouse. If your first question is “How will engineers ingest, transform, and model raw data?”, start with Lakehouse.
Getting Started
A practical path for standing up your first SQL Database in Fabric workload.
1. Confirm Fabric capacity
Make sure you have a supported Fabric capacity available, starting with F2+, and that the target workspace is assigned to that capacity.
2. Create the database item
In your workspace, create a new SQL Database item and place it alongside the lakehouse, warehouse, or BI assets that will consume its replicated data.
3. Design the schema
Define tables, relationships, keys, and integrity constraints with the same discipline you would apply to any production relational system.
4. Connect your application
Use a connection string and authenticate with SQL authentication or Microsoft Entra ID, depending on your application and identity requirements.
5. Verify OneLake replication
Confirm that your transactional data is appearing automatically in OneLake so analytics teams can begin working from the replicated representation.
6. Build BI on top
Create a Direct Lake semantic model on the replicated data and validate that the reporting experience meets both freshness and performance expectations.
7. Wire in Git integration
Use Git integration for schema and lifecycle management so database changes can align with the rest of your Fabric Dev/Test/Prod workflow.
Begin with a focused workload such as order management, ticketing, or reference/master data for an internal app. That gives you a realistic way to validate transactional behavior, replication timing, and BI integration before betting a broad portfolio on the new pattern.
Best Practices
Design and operate SQL Database in Fabric intentionally so it complements the rest of your Fabric architecture.
- Use SQL Database for transactional workloads: Treat it as the operational relational store, not as a substitute for a large analytics warehouse.
- Lean on automatic OneLake replication: Prefer the built-in path instead of creating avoidable ETL pipelines that duplicate effort and increase drift risk.
- Use Direct Lake for BI: Build semantic models on the replicated OneLake data rather than pushing heavy reporting workloads onto the transactional path.
- Apply row-level security in the semantic model: This is usually the right control point for report consumers and shared BI experiences.
- Monitor CU consumption carefully: High-concurrency OLTP patterns can consume significant Fabric capacity, especially when paired with active analytics workloads.
- Use Database Hub for mixed estates: If you operate Azure SQL, PostgreSQL, MySQL, Cosmos DB, and Fabric databases together, the unified pane can simplify governance and operations.
- Keep the workload regionally aligned: Place databases in the same region as the Fabric capacity whenever possible to reduce latency and avoid unnecessary cross-region complexity.
Use SQL Database in Fabric for: transactions, app state, operational systems of record Use Warehouse for: curated analytical serving layers and BI-heavy SQL workloads Use Lakehouse for: ingestion, transformation, data science, and Spark-first engineering Use OneLake replication as: the bridge between OLTP and analytics
Resources
Official references and follow-up reading for SQL Database in Fabric and related announcements.
📚 Official Documentation
SQL Database in Fabric Overview ↗ Fabric Databases Documentation Hub ↗ OneLake Overview ↗ Direct Lake Overview ↗📰 Event Context
FabCon 2026 announcements in this guide →📎 Related Pages
Best Practices — workload selection and BI guidance → Data Integration — mirroring and OneLake patterns → Architecture — core Fabric concepts →Because SQL Database in Fabric and Database Hub are fast-moving experiences, check the latest documentation and FabCon / Microsoft Fabric release notes before finalizing production design assumptions.