Get Free Tips
MSSQLTips.com
Home » SQL Databases in Fabric
Microsoft Fabric

SQL Databases in Fabric

written by Jared Westover 0 comments

Problem

Over the past few months, I’ve toyed with Microsoft Fabric, focusing on the Data Factory and Power BI experiences. Everything I’ve developed so far is in the proof-of-concept (POC) phase. Naturally, I’m skeptical about new game-changing features, and Fabric is no exception. Any new flashy tech brings bugs along in the early stages. We’ve all been there, working for weeks on a project to have random bugs throw a wrench in everything.

When Microsoft announced SQL databases in Fabric, I was intrigued. After watching the Ignite session, Power AI apps with insights from SQL database in Fabric, a few features instantly stood out, and I want to share my first impressions.

Solution

In this article, I’ll discuss what SQL databases in Fabric offer and why you might create one in Fabric instead of a traditional Azure SQL database. I’ll focus on core questions like: What’s involved in creating a Fabric SQL database? How does it integrate with other Microsoft Fabric components? How does it compare to existing Azure SQL databases? By the end, you’ll better understand SQL databases in Microsoft Fabric and know why and how to create one today.

Exploring SQL Databases in Fabric

I started working with Azure SQL Database in 2015 after a decade of experience on SQL Server. My first impression of Azure SQL Database was that it felt buggy and performance stunk. However, Microsoft has worked hard to build a reliable and cost-effective product over the years. These days, creating a serverless database is my go-to solution for most new projects. To be clear, I’m not getting paid by them for saying that!

What are SQL databases in Fabric? That’s a great question. And who better to answer than Microsoft? Microsoft defines a SQL database in Fabric as a developer-friendly transactional database based on Azure SQL Database, allowing you to easily create an operational database in Fabric. A SQL database in Fabric uses the same SQL Database Engine as Azure SQL Database. It’s a database you create in Fabric. Well, that’s a circular definition, isn’t it? Maybe a simpler way to think about them is as the first Software as a Service (SaaS) SQL offering.

Why create a SQL database in Fabric? The answer comes down to one primary point: its seamless integration with other features in Fabric. If you don’t currently use other Fabric features and have no plans to do so, then creating a Fabric database isn’t likely the right choice for you. There, I said it: If you don’t plan on integrating your Fabric databases with other Fabric tools, I wouldn’t create one.

In the following sections, I’ll highlight the three features that stood out the most during the Ignite session:

  • Speedy and easy database creation.
  • Integration with other Fabric experiences.
  • Insightful performance dashboards.

Spin Up Your First Fabric Database

One of the features that impressed me the most was how easy it was to create a database in Fabric. I thought creating an Azure SQL Database was easy until I tried this new experience. The process is so fast that you might think something went wrong. While watching the demo, I doubted it could be this quick and easy. However, once I tried it myself, I was a believer.

I’m going to create a database in a demo Fabric workspace. You can do this using the free trial or a workspace with Fabric Premium Capacity enabled. If you don’t see a database option, ensure it’s enabled in the tenant settings since it’s a preview feature. Remember that the preview feature is only enabled in some regions at the time of this writing, so you might not see it until later.

To follow along, navigate to a Fabric workspace, select New Item, and SQL database (preview).

Creating Database

Then, give it a name.

Naming Database

After a few clicks, you have an empty, serverless database ready for action.

Viewing Database

You can connect to the database using SQL Server Management Studio (SSMS). Click the Open in button, then SQL Server Management Studio to show the connection string.

SSMS

Unfortunately, the database name has a GUID-like suffix. Having the GUID in the name isn’t ideal, but it’s better than having it as the prefix.

If I were already in a Fabric workspace, I would likely stay there to run queries—I know, SQL Server heresy.

There are no settings for using a specific vCore count or other traditional setup options. Apparently, this level of convenience comes at a cost. One silly gripe I have is the purple logo for Databases. I have nothing against purple, but it doesn’t remind me of a database.

SQL Databases

Integration with Other Fabric Experiences

After reviewing Microsoft documentation and the Ignite sessions on databases, I found that Fabric keeps the .mdf and .ldf files in blob storage. This architecture is like Azure SQL Database. However, what sets SQL databases in Fabric apart is that your data is also mirrored in the Delta Parquet format within OneLake. This mirroring allows integration with Fabric’s other data engineering experiences using cross-database queries.

database details

Microsoft claims mirroring is near real-time, but I’ve found it takes 2-3 minutes to complete during testing. The delay might be due to my free trial version of Fabric, and honestly, a couple of minutes isn’t bad—unless you’ve promised stakeholders real-time data with no delay. Microsoft published a page titled “Limitations for Fabric SQL database mirroring (preview)” dedicated to the limitations of mirroring; make sure you review it before taking the plunge.

Why is mirroring so helpful? Imagine a data engineering team using a Fabric Warehouse and needing to include operational data in their queries. With SQL databases in Fabric, you can seamlessly query across both experiences using the mirrored Delta Parquet format. This functionality eliminates the need for an ETL (Extract, Transform, Load) process to bring the operational data into the Warehouse. It reminds me of linked servers in SQL Server but with an easier setup.

This kind of integration, not just with Warehouses but also with other experiences, including Power BI and Data Factory, is precisely why I might recommend creating and using a database in Fabric. You could argue that you’re still paying double for the storage since you have the database files and the additional Delta Parquet files, but storage is typically the cheapest part.

Monitoring with the Performance Dashboard

The final demo, which highlighted the performance dashboard, caught me off guard. Erin Stellato is one of the best additions to Microsoft’s SQL team, and when she entered the stage, I knew we were in for something special. Erin’s demo of the performance dashboards didn’t disappoint; it was informative, concise, and lasted just a couple of minutes. Think of the performance dashboard as the console of a fast sports car; it gives you real-time insights into how everything is performing, allowing you to take immediate action.

Performance dashboard

With the performance dashboard, you can find:

  • Queries taking a long time to execute.
  • Which queries are consuming the most CPU.
  • The number of user connections.
  • Blocking sessions and much more!

It also includes three alerts informing you when CPU consumption, blocked queries, and allocated database size exceed the defined threshold. Honestly, I didn’t expect this level of performance insights right from the start.

If someone creates a database in Fabric, I assume they come from more of an analytics or development background, not a hardcore DBA. With that audience in mind, some performance insights, such as the Request per second, might be hard to understand. However, you’ll feel right at home if you have experience with Query Store or third-party tools like dbWatch or Redgate SQL Monitor.

The performance dashboard is a prime topic for authors to expand in upcoming articles. I plan to explore more features in the future, including automatic index creation and general performance.

Downsides

Now, you might ask yourself, “Why isn’t he talking about glaring downsides?” It’s a fair question. For this article, I wanted to focus on the positives of this new addition to the SQL family. Sometimes, pointing out the negatives is too easy, especially with new products. I’m sure countless articles and videos will dive into all the downsides in the coming months.

Summary

Who should use Fabric databases? Suppose you need complete control over the service configuration, such as the number of vCores, firewall settings, and security. In that case, a database in Fabric probably isn’t the right fit for your environment. However, creating a database in Fabric could be a great option if you’re looking for a SaaS offering that eliminates nearly all configuration concerns and you’re already using Fabric.

Will users adopt Fabric databases in the coming months? It depends on whether it meets people’s needs. As someone with a background where analytics and reports were an afterthought, I wouldn’t have started with Fabric. If your team is comprised mainly of data engineers who have no interest in or desire for the database administrative aspects of SQL, then sure, I could see users adopting this. I would like to hear more from Microsoft regarding their target audience. Even if their answer is as simple as saying the target audience consists of current Fabric users who want a SaaS database, I’d be okay with that answer. When Microsoft introduced Dataverse, I thought they had a clear citizen developer audience in mind; perhaps Fabric databases are for the so-called citizen DBAs.

What are your thoughts on Microsoft’s decision to include databases in Fabric? Please leave your comments below.

Next Steps

Copyright (c) 2006-2025 Edgewood Solutions, LLC All rights reserved
sql server 2025 guide