Fabric SQL Database - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work, fabric and SQL. Sound like two different things, but Microsoft built them into one. It's called a SQL database in fabric, and underneath it runs the same engine that powers Azure SQL database. You might think it's just a familiar database in a new wrapper, but it does something with your data on its own. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. By the end, you'll know what a fabric SQL database is, how it lines up against Azure SQL database, how it uses your fabric capacity and where its limits are. What a fabric SQL database really is. Let's start with the plainest possible answer, because it really is this simple.

0:42 A SQL database in fabric is an organized place to keep records, and that's all a database is. Picture a table of customers with a name in one column, an email address in another, and the date they first ordered in a third stack a few hundred tables like that. Then wire them together so one table can point at another, and you have what people call a relational database. It's the quiet workhorse behind almost every business app you've ever clicked on. Then there's the sequel part of the name, and it's less scary than it sounds. SQL is the language you use to ask that database questions. A simple request like show me every customer who ordered last week is a SQL query. When someone says they work with a SQL database, they mean a database you talk to in that language. The word transactional trips people up too.

1:22 So let's take it slowly. A transactional database handles the moment to moment work of an app. The ordinary reads and writes that happen all day long. Someone clicks, buy the app, writes a single row of data, and the database confirms it in a fraction of a second. That tiny exchange is called a transaction, and a good one handles thousands of them without tripping over itself. There's a reason Microsoft put this database inside fabric instead of leaving it in Azure, and it comes down to an old split, the database that runs your app and the warehouse that runs your reports have always lived in two different worlds. For years, the only bridge between them was a copy. You copied the data on a schedule, you fixed the copy when it broke, and you explain to someone why last night's numbers didn't match this morning's. This database is aimed squarely at that gap.

2:02 Now for the part that should put you at ease, a SQL database and fabric uses the same SQL database engine as Azure SQL database, and that engine traces all the way back to SQL server. The commands you'd learn for any one of them carry over to the others. So the t-SQL you write once tends to work across all three. It's also a managed service, which means there's no server for you to patch and no version to install. You open a fabric workspace, create the database the same way you'd create any other item. Give it a name and it's ready to use. So the short version of the name is this. It's a database. You talk to it in SQL and it's built for the everyday work of an app. The fabric part is about where it lives and what it does with your data afterward. Creating it produces two things, not one. You get the database itself and you also get a second item called a SQL analytics endpoint.

2:44 Hold on to that name because that endpoint is how the analytics half of the story works. And we'll come back to it in a few minutes. It's also the piece that makes this database more interesting than it first appears. Why it feels like Azure SQL and where it doesn't. If you've touched Azure SQL database before, this will feel familiar in the best way. It's the same engine, the same t-SQL, and the same tools. You can connect with SQL Server Management Studio, the Msql extension for Visual Studio Code or the SQL CMD command line backups happen automatically and point in time. Restore works the way you'd expect, where you pick a moment in the past and get the database back exactly as it was. The portability is worth knowing about, too, because it means you're not sealed in. A tool called sickle package can export an entire database into a single file and import it somewhere else later.

3:27 That's how teams move a database between environments without rebuilding it by hand. Fabric also connects to git, so the database structure can live under source control. Next to everything else, your team tracks where the two pathways is in how much they ask of you. Azure SQL database hands you more control and control comes with more setup. If you want that databases data to show up inside fabric, you turn on mirroring yourself, and then you choose which tables get copied over a SQL database in fabric skips that step entirely because mirroring switches on as soon as the database exists and stays on the trade for that convenience is a handful of features you'd find on the Azure side. There's no elastic pool by name, though a single fabric capacity spread across workspaces gets you a similar shared resource effect.

4:07 There's no SQL server agent for scheduling jobs. So Microsoft points you toward data factory pipelines or Apache Airflow jobs instead. Those gaps won't matter to a lot of beginners, but they catch people who assume that same engine means same everything. None of this is meant to scare you off. For a beginner, the useful takeaway is that the day to day experience of writing queries and getting answers is almost identical to Azure SQL database, and the differences show up in the platform around the database rather than in the database itself. Backups deserve a sentence of their own because they're the thing that saves you when something goes wrong. They run automatically from the moment the database exists. They're copied across separate facilities for safety, and they stick around for seven days point in time. Restore lets you wind the clock back to a specific moment, which is the difference between a bad afternoon and a lost business.

4:52 So the honest way to frame this is that it isn't a fight between two products, and neither one is going anywhere. They're the same family aimed at different homes. One lives in Azure as a standalone service. You configure yourself and the other lives inside fabric right next to your analytics. The copy that makes itself. The moment you create the database fabric starts copying your data into one leg. And that single fact is the reason this database exists in fabric at all. One lake is Microsoft's one storage layer for fabric. The single place where all the different fabric items keep their data. That copying is called mirroring, and it works continuously as you save rows. Microsoft describes the delay as near real time, which is a fair description with one caveat. A practitioner who tested it on a trial capacity measured roughly two to three minutes for changes to show up, so plan for fast rather than instant.

5:37 What sets this apart from mirroring you may have set up before is that you don't do anything. It starts on its own. When the database is created and every supported table gets mirrored as soon as you build it, you don't pick and choose tables, and you can't leave one behind by accident. The copy is stored as delta parquet, which is an open file format, and open is the word that matters here. Because the data sits in an open format, it isn't trapped inside one tool. Anything that can read Delta can read your copy. Two small details are worth knowing because they come up in real projects. Only regular tables get mirrored, so views and temporary tables don't come along for the ride, and the copy stays inside your own fabric tenant, which means your data doesn't get shipped off to some other company's servers along the way. Then there's the SQL analytics endpoint, the second item fabric created alongside your database.

6:20 Think of it as a read only window onto the copy. When you run a query through that endpoint, you're reading the copied data rather than the live database. A heavy report can't drag down the app that people are using. Read only cuts both ways, and that's a good thing, because it means nobody can write to the copy by mistake and corrupt the records your app depends on. For a beginner, this is where it pays off. This is exactly the step that normally needs a pipeline. The old way meant extracting data from the app database, reshaping it for reporting and loading it somewhere else on a schedule. That routine has a name and people call it ETL for supported tables. The automatic copy replaces that whole job. If you've ever waited on an overnight job to refresh a report, you already know why this is a big deal. The data you just saved is already on its way to the analytics side, and nobody had to write a single line of code to make that happen.

7:05 There's a bonus for anyone who lives in power BI because the copy lands as delta tables. Power BI can read it in direct Lake mode, which pulls the data without importing a separate copy. First, think about what the copy means for a report you build. You point power BI at the SQL analytics endpoint, and it sees your tables as if they had always been sitting there waiting for you. There's no export step, no refresh window to schedule, and no spreadsheet. Someone emails around at the end of the month, the copy does something bigger than a report, though it changes a choice you've probably been forced to make. And that's what we're looking at next. One database, two jobs. There's a word for what you get when one data set serves both sides of the house, and it's translated it sounds like marketing, but it's just a mashup of transactional and analytical, and it describes something concrete.

7:46 Watch it work. Before I explain it. An app saves a customer's order. A couple of minutes later, a power BI report built on the SQL analytics endpoint shows this week's orders ticking upward. It's the same data the whole way through, with no handoff and no separate reporting database to keep in sync. Picture a small support team instead. Their ticketing app writes every new case into the database, and their manager wants a dashboard showing how many cases are still open. In the old setup, that dashboard would need its own copy of the data and its own refresh schedule. Here, the dashboard reads the same mirrored tables the app is already feeding, and the two stay in step without anyone playing traffic cop. The read only copy is what makes this safe. The report reads the copy while the app keeps writing to the original, a dashboard scanning millions of rows doesn't compete with the checkout page for the same resources.

8:31 One is doing the heavy reading and the other stays quick for the people using it. You can also reach further than one database from the SQL analytics endpoint. You can join your mirrored tables with a warehouse or a lake house in a single query by using three part names. That's a fancy way of saying you can point at a table in another fabric item by its full name. The query stitches the pieces together. This corrects an assumption a lot of beginners carry around. It's easy to assume an app database and a reporting database have to be two separate things, kept in sync by a job that breaks every other weekend. In this pattern, they don't have to be. The payoff for a beginner is simple. You learn one database, not two, and you stop treating reporting as a separate project with its own infrastructure. That's less to build, less to maintain, and fewer places for the numbers to disagree.

9:12 How it uses your fabric capacity to understand the cost, you first need one plain idea. And that's capacity. Fabric runs on a shared pool of computing power. You buy measured in units called capacity units or queues. Every workload in fabric draws from that pool, and this database is no different. This is the part where beginners get nervous. And that's fair because the database spends from the same budget as everything else in fabric. The conversion between capacity and database power is worth seeing. Once one capacity unit equals about zero point three eight three database cores, which flips to one core equaling two point six one eleven capacity units and sixty four capacity, gives you sixty four capacity units, and that works out to roughly twenty four point five V cores for the database. You don't need to memorize any of that, but what matters is that the databases muscle is tied to the capacity you already own.

9:57 The database is serverless, which changes how it builds. It scales up when demand rises and scales back down. When demand falls after fifteen minutes with no activity, it releases all its compute and the compute bill drops to zero. Storage keeps billing the whole time because your data is still sitting there, whether anyone is querying it or not. Microsoft's own example makes the idle behavior concrete. Say a database works hard for two minutes and then sits quiet. It gets billed for those two minutes, plus fifteen more minutes of being kept online, which is seventeen minutes of compute in total. Those extra minutes are deliberate because they keep the database warm, so the next person who connects doesn't hit a cold start. The storage side is simpler and steadier. Storage builds for the full hour. Whether the database is busy or asleep, the backup storage that comes with it is free up to the size of your database.

10:39 And if your backups grow larger than the database itself, you pay only for the part that goes over. There are guardrails. If you want them, you can set a maximum V core limit of two, four, or thirty two V cores with thirty two as the default. That cap decides how much of a shared capacity one database can eat during a spike. Lower caps come with smaller storage ceilings, too, so two V cores tops out at five hundred twelve gigabyte and four V cores at seven hundred and fifty six Gbyte, while the thirty two V core default allows up to four TB. The headline limits are easy to hold in your head. A database can reach thirty two cores and four TB of storage, and a single workspace can hold up to one hundred and fifty of them. A trial capacity is capped at three databases. Two numbers are worth remembering when you plan a budget. Compute is the part that moves up and down with use, and storage is the part that stays steady.

11:22 If you can predict your storage, you've already predicted most of your bill. When you want to see where the units go, the Fabric capacity Metrics app breaks it down, and this database shows up under the SQL database item kind. Your usage also lands in Microsoft Cost Management under your Azure subscription, which is where the bill arrives. If a cloud bill has ever landed with no clue which service caused it, this is the view that answers that question, where it fits and where it stops. Microsoft points to four patterns where this database earns its place, and they're worth hearing in plain terms. The first is intelligent apps and AI, where the database can hold vector data for search and retrieval patterns. The second is reverse ETL, where you push curated analytics back into an app so it can act on them. The third is an operational data store, where you gather data from several systems into one near real time place for reporting.

12:07 The fourth is the idea we just covered, where the app and the analyst share the same data. The fit test comes down to one question. If you already use fabric and you want your operational data living inside it, this is the natural home and the automatic copy is the reason. If you don't use fabric at all, a plain Azure SQL database is usually the simpler and more familiar choice. That's not a knock on either product, it's just the honest line. One practical note before you go looking for it, the feature has to be available in your tenant's home region as well as the region your capacity sits in, so it won't appear everywhere at once. When the option isn't there, that's usually the reason the limits are real, and knowing them is what keeps you from picking the wrong tool. There's no always encrypted for encrypting individual columns, no ledger tables, no in-memory tables, no change data capture, and no distributed transactions that span systems.

12:51 You can't place it inside your own virtual network since VNet integration isn't there and server level roles don't exist, scheduling jobs isn't built in either, which is why the data factory and airflow suggestion keeps coming up. None of that makes it a dead end. Private links are available at the tenant level, with workspace level links still in preview. Backups run on their own and are zone redundant, so a single facility going down won't take your data with it. If you're moving an existing SQL Server or Azure SQL database over, there's a path for that too. The Fabric Migration Assistant handles the move. Standing in for the Azure Migration Services you might have read about, there's a simple way to think about who this is for if you're comfortable tuning servers and managing network rules, a standard Azure SQL database will feel like home. If you'd rather not think about any of that and you just want your data close to your reports, this database was built with you in mind.

13:36 It's the same work teams have done for years, just with fewer moving parts and one fewer copy of the data to babysit. The short recap and one question for you. So here's the short version. A SQL database in fabric is a normal relational database built on the same engine as Azure SQL database that lives inside Microsoft Fabric. It copies itself into one lake automatically in an open format, so one data set can serve your app and your analysts at the same time. It runs serverless on your fabric capacity. It stops charging for compute after fifteen minutes, and it carries real limits. You should weigh before you commit. The real shift here isn't a new database at all. It's that you stop shuttling data between systems and let it sit in one place where both sides can reach it. If you want more Microsoft tools explained without the jargon, subscribe to M365 FM.

14:20 And here's the question I'll leave you with. If you had to point a database like this at a single job first, would it be the app that writes the data or the report that reads it?