What SQL database in Fabric is#
SQL database in Fabric is a developer-oriented transactional database engine that shares the same underlying SQL Database Engine as Azure SQL Database, making it the designated home for OLTP (transactional) workloads inside the Fabric platform [S1]. The T-SQL you already know works here — it's the familiar Azure SQL engine running as a first-class Fabric item, not a new dialect.
Every write becomes an analytics-ready copy, automatically#
The defining trait of SQL database in Fabric is what happens the moment you write to it. The platform automatically and continuously replicates your data into OneLake in near-real time, converting it to Parquet format so downstream analytical services — Spark, notebooks, Power BI, data engineering pipelines — can consume it without any manual export step [S1]. Provisioning a database also automatically creates a companion SQL analytics endpoint: read-only analytical access to that replicated OneLake data, isolated from the transactional workload so heavy reporting queries never compete with your app's live writes [S1].
Operations you don't have to do yourself#
The database ships with automatic tuning enabled by default, including automatic index creation, so routine index management is handled autonomously [S1]. Connecting is Entra-only: SQL authentication is not supported, and any user, service principal, or group needs at least the Read item permission on the database before a connection succeeds [S1].
A worked example#
Say you're building an order-tracking app. You provision a SQL database in a Fabric workspace, create an Orders table with standard T-SQL, and write new orders through an Entra-authenticated connection [S1]. Those rows land in OneLake as Parquet, queryable read-only through the analytics endpoint. A practitioner pattern goes further: read the database's automatically replicated OneLake copy directly as a Spark table and join it with lakehouse gold-layer data, giving recent transactional orders alongside historical analytics without querying the live OLTP engine at all [S2]. Moving that schema to another environment later is a SqlPackage job — .bacpac import/export and .dacpac deployments support CI/CD-style incremental changes [S1].
What goes wrong#
- Expecting instant analytics consistency. Replication into OneLake is near-real time, not synchronous — a write and its visibility on the analytics endpoint aren't the same instant [S1].
- Trying SQL logins. Authentication is Entra ID only; SQL authentication attempts fail outright [S1].
- Querying the analytics endpoint for OLTP writes. It's read-only by design, isolated so it can't affect the transactional workload [S1].
- Forgetting the Read item permission gate. Even a valid Entra identity is refused without Read item permission on the item itself [S1].
The engine also reaches beyond core OLTP — it supports vector data types and integrates with Azure OpenAI and frameworks like LangChain and Semantic Kernel for RAG and semantic search [S1] — and Fabric's mid-2026 roadmap still lists a migration assistant and full collation support as Preview items [S3].