Mirroring vs. Shortcuts in Microsoft Fabric: Which One Should You Use?

A few days ago, I shared a short LinkedIn post in which I condensed key differences and use cases for both mirroring and shortcuts in Microsoft Fabric. Since the post sparked some nice conversation and opened a few additional question, I decided to cover the same topic here, so that it doesn’t get lost in LinkedIn’s “jungle”:)

But, before we move to the final showdown, let’s take one step back and explain what mirroring and shortcuts are. I’ve already covered both in detail: in this article, I discussed why I consider mirroring a big thing in Fabric. And, what should I say about shortcuts? This is definitely one of my top 5 features in the entire Fabric ecosystem! I covered shortcuts in this article.

TL; DR: Both features enable the “One Copy” mantra that Fabric heavily promotes. And, although they share a lot of similarities from that “One Copy” point of view, as well as “No ETL setup” approach, they work completely differently behind the scenes, and have different use cases.

So, let’s explore these differences:

First and foremost, thanks to Miles Cole for creating these amazing Fabric drawings that I’m heavily using with the Excalidraw tool.

The key difference between mirroring and shortcuts is the data movement. With mirroring, data from the source is physically ingested into OneLake, which means that it counts as a Fabric storage (although you get a certain amount of free storage depending on the F SKU you are using). Supported data sources differ between mirroring and shortcuts. Simply said, if you want to have, let’s say, Azure SQL database data available in near real-time in Fabric, without implementing the ETL workflow, shortcuts are not an option, because they don’t support Azure SQL database as a source. Finally, the performance of the mirrored database is highly predictable and optimized, since the data is now stored locally in Fabric.

On the other hand, shortcuts create a virtual copy of the data, while the physical data stays in its original location outside of Fabric. Supported data sources are AWS S3, Google Cloud Platform, ADLS Gen2, and Dataverse. Finally, performance mostly depends on the external system, unless the data is cached in OneLake, which may happen under specific circumstances.

Specifics about the Databricks data source…

Please pay attention to the specific implementation of the mirroring feature for the Azure Databricks Unity Catalog as a data source. There are three types of mirroring feature implementation in Microsoft Fabric:

• Database – “classic” mirroring, where the entire database or individual database tables are replicated in OneLake. Supported data sources (as of May 2025): Azure SQL DB, Azure SQL Managed Instance, Snowflake, Cosmos DB
• Metadata – synchronizes metadata only! Things like catalog names, schemas, and tables. No “real” data is physically moved to Fabric! This type is used for mirroring Azure Databricks Unity Catalog
• Open – the most flexible one, because it enables any application to write change data directly into a mirrored database in Fabric

So, when you want Azure Databricks Unity Catalog replicated in Microsoft Fabric, the implementation is hybrid (mirroring + shortcuts):

• A mirrored database WILL be created in Microsoft Fabric. This database contains Unity Catalog metadata only (the Catalog structure)
• Physical data from Unity Catalog STAYS in Databricks and can be accessed by using shortcuts

This is at least how it works in preview, and you can find more details here.

Conclusion

Both mirroring and shortcuts are amazing features that enable easy integration and unification of the data stored outside of OneLake, without the need to set up and manage complex ETL processes. However, their implementation and use cases are very different. Thus, understanding when to use which might help you in building the optimal Microsoft Fabric architecture.

Thanks for reading!

Last Updated on May 7, 2025 by Nikola

Spread the music: