Microsoft Fabric Mirrored Databases - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What a mirrored database actually is. Microsoft Fabric can keep a copy of your database current within about fifteen seconds. That copy sits next to the rest of your data, and it stays in sync without you building pipelines or running jobs overnight, your company probably already owns the answers it needs, and they're locked in a database nobody can easily report on. A mirrored database is how fabric fixes that, and it's simpler than the name makes it sound. By the end, you'll know what it is, what it costs, and the limits that trip people up. Start with the plain version, because the name hides how simple the idea really is. A mirrored database is a live read only copy of a database you already have, and it sits inside Microsoft Fabric. Nothing writes to that copy except the system that keeps it current, and you can't change the original through it either. It exists so you can read the data, query it, and build reports on it without touching the database. Your app depends on the word mirrored is doing the heavy lifting there. A mirror shows you what's in front of it, and it doesn't let you reach through the glass to rearrange the room. That's the whole deal. You get a faithful view of your data, and the original keeps running exactly as it was. Picture a small online shop. Every order the shop takes lands in a database and that database is busy all day handling payments, stock and shipping. The owner wants a sales dashboard, but pointing a dashboard at the live database is a bad idea, because heavy reporting can slow down the very system. Taking orders. So fabric makes a second copy for reading only, and it keeps that copy fresh without anyone watching it. There's one word you'll hear a lot, and it's worth diffusing now. A pipeline is the set of chores people normally build by hand to move data from one place to another. Mirroring skips those chores so you don't schedule a nightly copy. You don't write code to move rows, and you don't babysit a job that fails on a Friday night. Two things are honest from the start, and both shape everything that follows. You can read from the copy but never write to it and it's near real time rather than instant. Why this exists at all. The problem it solves is older than cloud computing. Companies rarely suffer from a lack of data. They suffer because the data they need sits in one system, while the tools that could explain it sit in another. An orders database lives in one place, a marketing warehouse lives somewhere else, and a finance spreadsheet lives on someone's laptop. So people build bridges between those places by hand. Someone writes a job that copies data every night, checks it in the morning, and fixes it when it breaks. That job works fine until it doesn't. And when it breaks on a Friday, nobody notices until Monday. The surprising part is where the real effort went. Everyone assumes the hard work is the analysis, the charts, and the insight. And that assumption is wrong. The hard work is the moving and once the data lands somewhere you can query directly, the analysis gets easy. Fast. That's the shift. Mirroring makes. It turns a long list of data moving chores into a short setup step. Because you point fabric at the database you already own instead of building the movement yourself, Microsoft calls mirroring a fully managed service, which means the company running the copying, the retrying and the syncing is not you. You set up a secure connection, choose a whole database, or just the tables you care about, and the system keeps it current from there. There's a reason this matters more than it used to. Data keeps piling up faster than teams can build pipelines to move it. So the gap between the data you have and the insight you can reach keeps widening. Mirroring closes that gap without asking you to hire a data engineering team first. The reason this exists is easy to say in one line your data is already valuable, and the only thing standing between it and the useful report is the work of moving it. Mirroring removes that work. How the copy stays in sync. Once you turn mirroring on three things happen in order and the order matters. First, fabric connects to your source and takes a starting snapshot. That first copy can take a while if your database is large, because it has to read the whole thing at least once. Then the interesting part starts after the snapshot. Fabric doesn't recopy everything. It watches for changes and folds only the changes into the copy. How it detects those changes depends on the source, and this is where the plumbing differs. SQL server versions from twenty sixteen through twenty twenty two lean on a built in feature called Change Data capture. SQL server twenty twenty five reads the database's transaction log, which is the running record of everything that happens in the database as your cosmos DB uses its continuous backup feature as the place it looks for changes. Picture the difference between photocopying an entire filing cabinet every night and dropping new letters into a tray as they arrive. Mirroring does the second one changes can land as fast as every fifteen seconds. That's the fastest pace Microsoft publishes, and it's worth treating as a best case rather than a promise. How fast your copy updates depends on where the source lives, where your fabric capacity sits, how much is changing, and how much bandwidth sits between them. Microsoft also notes that a quiet system backs off and slows its checks, which saves work on your source database. The changes land in one lake, which is fabric's storage layer, and they're saved in an open format called Delta Lake. Open matters here because it means tools outside fabric can read the same files. The difference between this and a scheduled copy is worth sitting with. A scheduled copy moves everything on a timer, so it's always a little behind and always moving more than it needs to. Mirroring moves only what changed and it moves it continuously. So the copy isn't a snapshot you refresh. It's a feed that follows your database. What you get once it's running. Turning on mirroring leaves two items in your fabric workspace, and both are worth knowing by name. The first is the mirrored database itself. It shows you the health of the copy and whether replication is running, and it gives you controls to start or stop it if something goes wrong with the connection. This is where you look first. The second is a SQL analytics endpoint, and this is the one people end up using. It's a read only doorway to the copied data, and it speaks the same query language that SQL users already know. You can explore tables, build views, and run reports, but you can't change anything because the whole point is to leave the original alone. From there, the copy becomes useful in several directions. You can query it with SQL connect familiar tools like SQL Server Management Studio, or the SQL extension for Visual Studio Code, or run spark notebooks against it for heavier work. The power BI connection is the part that tends to excite people. It can read the copy directly in direct lake mode, which means no import step and no schedule to wait on. You can also join the copy to other things in a single query. One statement can pull from a mirrored database, a warehouse, and the lake house at the same time, which is how you compare live operational data with historical analytical data without exporting anything. One thing is worth saying plainly, and it's that you don't need to understand all of this to get value from it. If you can open a power BI report, you can already use the result. The plumbing is fabric's job, and your job is to ask better questions of the data you finally have in one place for the shop owner. The difference is easy to feel. Yesterday the sales dashboard was a snapshot from last night. Today it's a report that shows an order from a minute ago. Where your data can come from. The list of sources is long and it keeps growing. So the useful thing is the shape of it rather than a fixed count. On the database side, you can mirror Azure SQL database SQL server from twenty sixteen all the way through twenty twenty five, Azure SQL Managed Instance and Azure Database for PostgreSQL. Azure database for MySQL is in preview. Snowflake, Google BigQuery, and Oracle are supported too, and SAP rounds out that group. Then there's the cosmos DB case, which stands on its own. Azure cosmos DB is a database built for apps rather than reports, and mirroring lets you analyze that app data without slowing the app down or burning through its request units. Two other flavors are worth knowing because they change what the word copy even means. Metadata mirroring doesn't move your data at all. It copies only the catalog, the names and schemas, and uses shortcuts that point at the live data, which is how Azure Databricks fits in. Open mirroring is for developers who want to write their own changes into fabric through a public API. Using the open Delta format. SharePoint lists can be mirrored too, and that matters more than it sounds, because a lot of real business data lives in a list someone built years ago and nobody has ever reported on. Notice how much of this list is stuff you might already own if your company runs SQL server or keeps a cosmos DB behind an app, or pays for snowflake. Those are all first class sources here. You're not being asked to adopt a new database. To use this, you're being asked to connect the one you have. One honest note applies to this whole list. Some of these sources are generally available and others are still in preview, which means their behavior can change if your database is on the list. That's the good news, and the current Microsoft documentation is the place to confirm its status before you commit. Where this pays off in real life, abstract features are easy to not add and hard to remember, so the useful move is to name the places mirroring earns its keep. One place it pays off is near real time dashboards on live operational data. A support lead can watch ticket volume climb during a bad afternoon. Instead of finding out the next morning, and a warehouse manager can see stock move as orders come in. Another is bringing your live systems and your analysis together in one place. Your orders sit in one system and your marketing spend sits in a warehouse, and normally those two never meet without an export. With the copy and fabric, one query can compare them, which is where a question like which campaign drove profitable orders stops being a research project. Then there's reporting on an on premises SQL server without moving it to the cloud by hand. Plenty of companies still run a SQL server in the server room, and mirroring gives them a way to report on it inside fabric without a migration project. You also get app data out of cosmos DB for analysis, because the copy happens without consuming the apps request units, the analytics team can explore freely. While the app keeps its performance, the Microsoft three hundred sixty five angle is quieter but real. A team's list of projects or requests can become a portable table without the usual export to Excel and email it around. That's the kind of small win that makes people stop dreading Monday. Reporting the pattern across all five is the same somewhere in your company. A database is doing real work, and someone is stuck copying pieces of it by hand to answer a question. Mirroring takes that copy job off their plate and hands them a live view instead. Every one of these assumes two things and both matter. Here, your source has to be on the supported list, and your fabric capacity has to be running. If either is missing, the whole thing sits still. What it costs and why that surprises people. This is the part people guess wrong, and the answer is better than most expect. The copy itself is cheap for database mirroring and open mirroring. The storage and the background compute are free up to a limit tied to the size of your fabric capacity. The rule Microsoft publishes is one free terabyte of mirroring storage for every capacity unit you buy. A capacity with sixty four capacity units, for example, comes with sixty four free terabytes set aside for mirroring, which is a serious amount of room before storage costs you anything. The compute that does the copying is free, too, and it doesn't eat into the capacity units you're paying for. That detail matters, since keeping the copy current doesn't compete with the reports people are running. What you do pay for is the querying. Every time someone runs SQL, opens a power BI report, or starts a spark job against the copy, that work is charged at the normal fabric rates you're paying for use, not for the copy sitting there. But here is the part no one tells you about mirroring a running fabric capacity is required if you pause your capacity to save money. Mirroring stops and no data replicates while it's paused. Pausing is a real cost saving move in fabric, but with mirroring, you're trading that saving for a stale copy. One more small setting is worth knowing. Mirroring cleans up old files on a schedule, and the default retention is one day for databases mirrored after the middle of June twenty twenty five, and seven days for older ones, you can shorten it to save space or lengthen it if you want to look back in time. Put together, that model is friendlier than people expect. The expensive part of most analytics setups is moving and storing copies of data and mirroring makes both of those close to free at the start. The money follows the questions people ask, not the data sitting still. The limits you should know before you start. Every tool has edges and this one has several. You should know before you build anything on it. The biggest limit is that the copy is read only you can read from it and report on it, but you can't write back to your source through fabric, and you can't use it as the database for your app if you need two way sync. This isn't that. Then there's the fact that this is not a backup and not a migration tool. It's a continuous analytical copy and it lives inside fabric. If your goal is disaster recovery or moving your database to a new home, mirroring is the wrong tool for the job. Latency is another one near. Real time is honest, but it isn't. Instant. Fifteen seconds is the fastest figure Microsoft publishes, and real world updates can be slower depending on region, volume, and network. The source specific limits matter most because they decide whether your database can be mirrored at all. For cosmos DB only NoSQL accounts are supported. It isn't available in sovereign clouds. You have to turn on continuous backup first and accounts with multiple write regions aren't supported. For Azure SQL database. The cheaper DTU tiers are out free basic and standard databases under one hundred Dtus aren't supported. For SQL server twenty twenty five. There's a twist. It needs a connection to Azure Arc, and it isn't supported on Linux or on Azure Virtual Machines. Right now, older SQL server versions are more forgiving. There's also a firewall consideration if your database isn't reachable from the internet, you'll need a data gateway, which is extra setup and extra moving parts. Finally, schema changes can get messy in cosmos DB. If you rename a property, you end up keeping both the old column and the new one, and the old one just shows empty values. If you change a property's data type to something that can't convert cleanly, the value shows up as null. None of this breaks anything, but it's the kind of thing that makes a report look wrong. Until you understand why none of these limits makes mirroring a bad choice, they narrow the cases where it's the right one. The teams that get burnt are the ones that assume a live copy replaces their backup, their migration plan, and their data warehouse all at once. It replaces none of those. And keep in mind that preview status is a moving target, so a source's behavior can shift between now and general availability. How this fits with Azure Microsoft three hundred sixty five and power BI. The last piece is where mirroring sits in the stack. You already use because that's what makes it click. Azure is almost always the source side. Azure SQL database, Azure Cosmos DB, Azure database for PostgreSQL, Azure database for MySQL and Azure SQL Managed instance all live in Azure. And those are the databases fabric connects to. Fabric is the analytics side. It's where the copy lands and its storage layer one lake comes with every fabric tenant, so you're not standing up a separate system just to hold the copy. Microsoft three hundred sixty five is where the data and the audience often already live. Your SharePoint lists can flow into fabric as reportable tables, and the people who read those reports are usually sitting in teams in power BI already, which means the insights land where the work happens. Power BI is the payoff layer. Direct Lake mode lets the report read the mirrored copy directly, so you don't import the data or wait on a scheduled refresh. A change in the source can show up in a report within seconds. Copilot sits on top of that because the data now lives in fabric, the AI features built into the platform can reach it. And that's one reason a lot of teams start mirroring in the first place. The mental model worth keeping is simple. Azure holds the live system fabric, keeps the read only copy, and power BI and Microsoft three hundred sixty five are where people look at it. None of this asks you to learn a new tool from scratch. If you already use power BI or you already work in Microsoft three hundred sixty five, you're mostly adding one connection and letting fabric do the rest. Put together a mirrored database, hands you a live read only view of a database you already own, kept current without pipelines or nightly jobs, the copy is mostly free, up to a ceiling set by your fabric capacity. The trade offs are read only access near real time rather than instant updates, and a real list of source specific limits that decides whether it works for your setup at all. That leaves one question for you. Which database in your world would you mirror first if it were this easy? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.