Fabric Mirroring - Simply Explained

0:00 Changes to your database can land in Microsoft Fabric as fast as fifteen seconds later. That is the promise of fabric mirroring, and it is not the same thing as copying your data once. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Most of us assume getting database data into fabric means building pipelines, but mirroring handles that for you. Today you will see how it works, what it lands in one lake and when to use it instead of a shortcut or a pipeline. Why your data is stuck. Think about the data you actually care about. It sits in a database built to run the business. One that takes orders, tracks customers, and keeps the day moving. That database is very good at its job, and it was never built to answer the kinds of questions a report asks.

0:40 Take questions like which region is growing fastest this quarter, or which product keeps coming back for a second look. So the moment someone wants a dashboard, the data has to get somewhere else first. And that trip is where most teams lose their time. It helps to picture the two jobs as different in kind. Your operational database is built for speed and safety on a small number of rows at a time. It can take an order and confirm a payment in a blink. An analytic system works the other way around, reading enormous piles of history to find a pattern. Asking one machine to do both jobs is why the data usually gets a second home, and the gap between the data you have and the answer you need is rarely about the data itself. Traditionally, that second home means building a pipeline. A pipeline is a piece of engineering that copies data from one place to another.

1:21 On a schedule. Someone has to build it, test it, watch it, and repair it. Every time something upstream changes. It works, but it's work, and for many teams, it becomes the slowest part of getting to an answer. A simple dashboard request can turn into a two week project before anyone has looked at a single number. Fabric mirroring takes a different route. Instead of you moving the data, fabric keeps a live copy of your external database inside one lake, and it refreshes that copy on its own. One lake is the single place where Microsoft fabric keeps all of your data. Each fabric tool can find what it needs there without hunting through separate systems. You aren't shipping your data off to a stranger either, because the copy lives inside your own fabric tenant. The part that surprises people is that mirroring isn't a one time export you run and forget.

2:04 It's a continuously kept copy that stays in step with the original, and it doesn't break the moment the source changes. Microsoft runs all of it for you as a managed service, you make the connection once, choose what to bring over and fabric carries the rest while you go do your actual job. How the copy actually gets there. Setting mirroring up is deliberately simple, and that simplicity is the point. You point fabric at your source database, sign in with a secure connection, and decide whether you want the whole database or just a few tables. From that moment on, fabric keeps the copy in sync and you never schedule a thing. There's no server to stand up, no job to babysit, and no script to fix. When a column name changes. One thing worth knowing is that the very first sync takes longer than the ones after it. Fabric has to copy everything that already exists, and only then does it switch to tracking changes.

2:48 A large database can take a while to catch up before it goes live, but after that first pass, the updates are small and steady. The mechanics are worth understanding because they explain why the copy stays fresh. Your source database already tracks its own changes, since that's how it knows what happened since the last time you looked. Mirroring taps into that record. Rather than reading every row over and over for a SQL server source, the database engine reads its own transaction log at a high frequency, and publishes the changes table by table to a small landing area inside fabric. Reading that log is cheap for the source, so your live traffic barely notices on the fabric side. A replication engine is always running. It watches for those newly published changes and merges them into the target table, adding new rows, updating changed ones, and removing the rows that were deleted.

3:32 Microsoft documents that changes can be published as fast as every fifteen seconds, which is why the copy feels live instead of nightly. There's some clever throttling built in as well. When the source goes quiet, the system backs off so it doesn't keep hammering a database that has nothing new to say that back off matters more than it sounds, because it means mirroring is polite to your source database, and you can turn it on during a busy day without holding your breath. What lands in one lake isn't a raw dump of your table's fabric. Converts the data into an open table format called Delta, which is the shared language every part of fabric can read. That single decision is what lets your mirrored data appear in power BI, in spark notebooks, and in plain SQL queries, without anyone rebuilding it by hand. One honest caveat before you plan around the number fifteen near real time isn't a promise of fifteen seconds on the dot.

4:15 The real pace depends on how far apart your source and your destination sit, how much is changing, and how much bandwidth runs between them. Keep that in mind, because a little later we'll look at the sources that don't copy their data at all. What you get once it's there. Once your data is sitting in one lake, it stops being special and starts behaving like any other fabric data. That's the whole point, because it means you don't have to learn a new tool to use it. If you're comfortable with SQL, you can query the mirrored database with ordinary t-SQL through what fabric calls a SQL analytics endpoint. That endpoint is a read only door onto your data, and it looks like a normal database to tools you already know, including SQL Server Management Studio for reporting. The interesting part is Direct Lake, because the mirrored data already sits in the delta format.

4:57 That power BI understands power BI can read those files directly. That means no importing a second copy into a semantic model and no nightly refresh window to wait for. You can also mix sources in a single query. Since everything lives in the same lake, you can join mirrored tables with tables from a warehouse or a lake house using three part names. Sharing works the way you'd hope you can give someone access to just the mirrored database without handing them the keys to the whole workspace. The usual guardrails still apply, like row level security that hides certain rows from certain people. One rule is worth memorizing the copy is read only. If something needs to change, you change it in the source system and let mirroring carry the update across. That keeps a single version of the truth and saves you from arguing about which copy is correct.

5:38 The bigger idea is that mirrored data isn't a dead end, it's a starting point you can build on with the same notebooks, pipelines, and models you'd use on any other fabric table. Whatever you already reach for to explore data in fabric will read the mirrored copy without complaint, because at the end of the day, it's just another delta table which sources you can mirror before you get attached to the idea, you want to know whether your data is on the list. The short answer is that it probably is, and the list keeps growing. On the database side, fabric can mirror Azure SQL database, SQL server, Azure SQL managed Instance, Azure database for PostgreSQL, MySQL, and Oracle. If your data lives in a data platform rather than a plain database, snowflake, Azure, Databricks, Google, BigQuery, and SAP are covered too.

6:20 There's even a cosmos DB mirror for teams working with that kind of store. Remember that twist I mentioned where some sources don't get a copy of their data at all? The reason comes down to three flavors of mirroring, and the flavor decides what actually happens to your data. The first is database mirroring, where fabric makes a real, continuously refreshed copy of your data inside one lake. The second is metadata mirroring, where fabric syncs only the catalog, meaning the names of your databases, schemas, and tables. It then reaches the actual data where it already lives by using shortcuts. The third is open mirroring, which is for developers and vendors who want to push their own change data into fabric through a public interface. Those flavors aren't random because they follow the source databases that store data in their own closed format like Azure SQL, cosmos DB, PostgreSQL, and Oracle get a real copy.

7:05 Since fabric can't read that format directly. Sources that already store data in open formats like Snowflake and Azure Databricks are reached in place. The data never moves, so you aren't paying to store a second copy of it. And that one detail often decides which sources are cheap for you and which ones add storage. A quick way to remember it is to ask what shape your data is already in. If it's locked inside a database that only its own engine can read, expect a copy. If it's already sitting in the open, expect a pointer. Some of these sources are newer and still labeled as preview, which simply means they aren't finished products yet. Treat the list as something that grows rather than something fixed. For a beginner, the flavor matters more than it sounds. It decides two things you'll feel directly, which are whether you're storing and paying for a copy and how the data stays fresh.

7:47 There's one more source that's easy to miss if you create a SQL database inside fabric itself, it's mirrored automatically, so you get the analytics side without setting anything up at all. Mirroring versus shortcuts versus pipelines. The question that trips up almost every beginner is the difference between a shortcut and mirroring. Since mirroring sometimes uses shortcuts under the hood, the clean answer comes down to scope and to who does the work. And once you see it, you won't mix them up again. A shortcut is a pointer. It adds a reference to specific tables, folders, or files, and the data never leaves where it lives. You decide exactly which pieces appear in one lake and where they show up, which makes shortcuts perfect for sharing one table across teams or stitching together data from several lakes.

8:28 The catch is that shortcuts only work with open formats, so if your source stores data in its own closed format, a shortcut has nothing to point at. Mirroring works at a bigger scale, it adds an entire external database or catalog to fabric as a unit, and then it either copies the data or reaches it in place, depending on the source. So the rule of thumb is simple a shortcut points at the part you choose, and mirroring brings in the whole database and lets fabric decide the best way to reach it. Microsoft puts it even more plainly in its own documentation, where it states that if your source stores data in a proprietary format, mirroring is your only option. The two can even work together, which is where the design really pays off. You mirror the source once, then hand out shortcuts to the tables each team needs, so a single connection ends up feeding the whole company.

9:10 Pipelines are a different animal altogether, and the difference is control. A pipeline is you building the data movement yourself, so you decide what gets copied when it runs, how it's transformed along the way and where it lands. That control is exactly why pipelines exist, and it's also why they take real effort to build and maintain. Mirroring deliberately gives up that control in exchange for almost no setup, which is a trade most beginners should be happy to make. The Fabric Decision Guide makes the choice surprisingly easy for curated data that you want to report on the kind of clean, ready to use data people call gold. Mirroring is described as the simplest and most cost effective path for raw data. You still need to clean and reshape. A copy job usually fits better for real time streams of events. You want event streams for complex orchestration, where you coordinate many steps with dependencies and error handling.

9:55 You want pipelines. The guide draws a clear line, and mirroring sits firmly on the simple side of it. A small scenario makes it concrete. A five person team keeps its sales data in an Azure SQL database. And once a live Power BI dashboard, they don't need transformations and they don't need to run it on a schedule they control for that team. Mirroring is the obvious answer, and the pipeline would be overkill. Flip the situation and the answer flips with it. The same team now needing to blend five sources into one reshaped table on a strict nightly schedule, reaches for a pipeline instead. That isn't a failure of mirroring, but a sign they picked the right tool for the job and what it costs and where it stops. Cost is where many beginners brace for bad news. So let's start with the good part for database mirroring and open mirroring. The storage and the background copying are free up to a limit tied to the size of your fabric capacity.

10:41 A capacity is the pool of computing power you buy in fabric. And the bigger the pool, the more free mirroring storage comes with it. The formula is generous and easy to remember. You get one free terabyte of mirroring storage for every capacity unit you purchase, so an F sixty four capacity comes with sixty four free terabytes reserved just for mirrored data. For a beginner running a small database, that ceiling is a long way off. Now the part people miss. Not everything is free, and it's worth knowing exactly where the meter starts. Querying your mirrored data. Whether you use SQL, power BI or spark is charged at normal rates because that's you using compute to do real work. You also start paying for storage once you pass the free mirroring limit, or when your capacity is paused. Since the free allowance only applies while the capacity is running.

11:22 Background replication itself is free and doesn't consume your capacity units at all, which is the part that surprises people most. There's one hard rule to plan around. Mirroring needs a running fabric capacity, so if you pause or delete that capacity, mirroring stops and nothing replicates until it comes back. Storage doesn't grow forever either. Mirroring automatically cleans up old files that are no longer needed, and the default is to keep one day of history for newer mirrored databases, while older ones keep seven. If you want more history for time travel, which lets you look at your data as it was on an earlier date, you can raise that setting when you want to save space. You can lower it when mirroring is the right move. That brings us to the practical part, which is when to actually reach for mirroring. The first and clearest case is an operational database that you want to report on without slowing it down.

12:06 Your database is busy serving customers, and the last thing you want is a heavy analytics query. Fighting with live traffic mirroring gives you a separate read only copy that reporting can hammer all day. While the original database keeps doing its job, that's exactly the scenario Microsoft uses as its own example, where a finance manager wants real time dashboards but can't let analytics queries touch the system's processing thousands of daily transactions. The second case is bringing an external warehouse or lake house into fabric, so you can query it alongside everything else. If your organization already runs Snowflake or Azure Databricks, mirroring lets that data show up in fabric next to your other tables. The third case is scale across teams. Instead of mirroring the same source once per team, you mirror it once in a central workspace and let other teams reach it through shortcuts.

12:50 Everyone then reads the same up to date data from a single connection, and nobody maintains a duplicate. One more signal that mirroring fits is the word live. If the people asking for the report care that the numbers are fresh and they usually do, mirroring hands you that freshness. Without a nightly job, you have to trust. Just as useful as knowing when mirroring is the wrong tool. If you need heavy transformations, like joining many sources or reshaping schemas, mirroring won't do it. A custom schedule isn't an option either, because mirroring runs continuously. Your data might need to land somewhere outside one lake, and that calls for a pipeline, a copy job, or an event stream instead. Mirroring is a focused tool, and it does that one thing extremely well, which is keeping a live query ready copy of your data close to where you analyze it.

13:31 Recap in one question. So here's where we landed. Fabric mirroring keeps a live analytics ready copy of your database inside one lake without you building a single pipeline that copy lands as open delta tables. Any fabric tool can read from power BI to spark to plain SQL. A shortcut references the specific data you choose, while mirroring brings in a whole database and handles the connection for you. A pipeline is what you build when you want full control and don't mind the work. And mirroring is free within a capacity based allowance. So here's the question I want to leave you with. If you could mirror one database into fabric tomorrow, which one would it be? Tell me in the comments because that's usually where the real use cases show up.