SQL database in Fabric is in preview: a first look at operational data in Fabric

Fabric just got its first operational database. Microsoft used Ignite 2024 to announce the public preview of SQL database in Microsoft Fabric, a transactional SQL database that lives in a Fabric workspace and copies its data to OneLake on its own.

Until now, Fabric has been an analytics platform. Your application databases lived somewhere else, and you built pipelines or set up mirroring to get the data in. Microsoft now says Fabric is evolving from an analytics platform to a data platform, and this preview is the first concrete step in that direction.

What it is built on

This is not a new engine. Microsoft states that SQL database in Fabric is built on the SQL Server and Azure SQL Database engine, so it is the T-SQL you already know. Your procedures and tuning instincts carry over.

What changes is the packaging. Creating a database only requires a name, and the database is ready in seconds. There is no page of choices about compute tiers, networking or storage. Authentication runs through Microsoft Entra, and permissions set at the workspace level are inherited by the database.

The announcement describes it as autonomous. In practice that means:

• High availability with zone redundancy, configured automatically.
• Storage and compute that scale with the workload.
• Missing indexes created by the system, plus the latest Intelligent Query Processing features.
• Automatic patching and automatic backups.

It also means less control, so test with your own workload before you trust it.

Two endpoints, one copy of the data

The part that matters most for data people is the OneLake integration. All data is replicated in near real time to Delta Parquet in OneLake. When you create a SQL database in Fabric, you get two endpoints:

1. The database itself, for your application and transactional work.
2. A SQL analytics endpoint that queries the replicated data in OneLake.

So the operational and analytical sides use the same data without you building anything in between. From the analytics endpoint you can query with the warehouse engine, or create shortcuts so a Lakehouse or a notebook can use the tables. Power BI gets a default semantic model that can use Direct Lake mode.

After two decades in data, I have built more "copy the OLTP data to the reporting side" jobs than I care to count. Removing that step is the most interesting promise in this announcement.

Who it is for

Microsoft is pitching this hard at developers building AI applications. The preview includes native vector and RAG support, the ability to call models via APIs from inside the database, and compatibility with frameworks such as LangChain and Semantic Kernel.

I think the audience is wider. Three groups should look at it:

• App developers who want a SQL database without running an Azure subscription, and who like source control. The database works with SDK-style SQL projects and Fabric Git integration, with both GitHub and Azure DevOps. You can also generate a GraphQL API on top of it in a couple of clicks.
• Fabric teams that need a small operational store next to their analytics: metadata tables, configuration, write-back from reports, or a staging area that needs real transactions.
• Power BI and analytics teams who currently depend on a separate Azure SQL Database for a handful of tables, and pay for it outside their Fabric capacity.

Billing and preview details

SQL database is a native Fabric item, so it consumes Fabric capacity units like any other workload. Compute is only charged when the database is actively used, and it scales automatically. Storage is billed separately each month, and so are the automatic backups, which are kept for seven days.

The timing is worth noting. According to the announcement, SQL database in Fabric is free until February 1, 2025. Compute and storage charges start on that date, and backup billing starts on March 1, 2025. That gives a clear window to test without touching your capacity budget.

A few more preview points from the announcement:

• Your tenant admin has to enable SQL database in Fabric before you can create one.
• It does not depend on a specific capacity, and it should be available in all Fabric regions by early December.
• Private Link support is planned at tenant level in January, with workspace level later.
• Auditing is coming in the following months, and customer-managed keys are only described as a future plan.

If you need auditing or customer-managed keys, this is for exploration now, not production.

What to try in the preview

I would use the free period to answer concrete questions, not to build a showcase. A sensible order:

1. Ask your tenant admin to enable the feature, and create a database in a test workspace.
2. Load sample data or a copy of a small real schema, and check that your T-SQL runs as expected.
3. Write a few rows and see how quickly they appear through the SQL analytics endpoint.
4. Build a Power BI report on the default semantic model and check Direct Lake behaviour.
5. Connect the workspace to Git and check how the database objects look in the repository.
6. Watch capacity usage, so you know roughly what this will cost when billing starts in February.

Step six is the one people skip. A free preview tells you nothing about cost unless you measure it.

Takeaway

SQL database in Fabric puts a familiar engine inside the platform where many of us already do analytics, and removes the copy job between operational and reporting data. The security and governance list is not complete yet, so treat it as a preview in the honest sense of the word.

Would you move a small operational database into Fabric, or does it belong in Azure SQL Database for now?

Sources

• Announcing SQL database in Microsoft Fabric (Preview) (Microsoft Fabric Updates Blog)
• Build AI apps faster and easier with SQL database in Fabric, now Public Preview (Azure SQL Dev Corner, 19 November 2024)