Modernize data integration strategy with Microsoft Fabric when using Snowflake and Databricks

Challenges solved by Microsoft Fabric

Microsoft Fabric is an end-to-end analytics platform that brings together data integration, data engineering, warehousing, real-time analytics, business intelligence, and AI-related experiences. It has grown tremendously within the community because it is solving a key problem: lowering the integration tax across data and analytics systems. To understand the integration tax, consider a mid-sized or large organization that wants to perform analytics and data processing. It may use several source systems, an analytics platform such as a warehouse or lakehouse, and yet another platform or vendor for orchestration. To generate insights, the organization must integrate these different systems (hence the term integration tax).

Fabric brings together a broad set of analytics capabilities within one platform, which can reduce the number of separate integrations an organization needs to design and operate. You can bring data into Fabric, store it in a warehouse or lakehouse, query and analyze it with Spark or T-SQL, visualize insights with Power BI, and support real-time scenarios with Real-Time Intelligence. Fabric also interoperates with platforms such as Snowflake and Databricks, helping organizations unify data and analytics across technologies while minimizing data movement and duplication.

The following diagram shows how these experiences come together as part of the Microsoft Fabric platform.

Figure: Microsoft Fabric brings data, analytics, AI, OneLake, and governance capabilities together on a unified platform.

OneLake serves as Fabric's unified logical data layer. Fabric-managed data resides in OneLake, while shortcuts and some mirroring scenarios can reference data that remains outside OneLake. If one team owns the data and another team in the organization needs access, the second team does not need to duplicate it. Instead, it can create a Fabric shortcut and work with the same copy of the data.

Beyond storage, OneLake also enables data-sharing and governance patterns across domains and workspaces. Organizations can expose data through shortcuts while maintaining ownership within the producing team, enabling data mesh architecture without duplicating datasets.

Integration options

We have discussed shortcuts briefly. Now let's look at how they work and at the other options available for making data accessible in Fabric:

• Shortcuts: Fabric lets you create a pointer to data in its existing location and access it without moving it. A shortcut is similar to a symbolic link or a Windows shortcut: the data source can differ from the location where users access it. For example, data can remain in Amazon S3 while a Fabric shortcut provides access to the required data. To users, the data appears to reside in Fabric even though it is retrieved from S3. Shortcut transformations also support selected transformations on shortcut data.
• Mirroring: For supported data sources, mirroring provides you with a low latency option to bring your data into Fabric. Depending on the source system, mirroring either continuously replicates data into OneLake or exposes the source through metadata mirroring and shortcuts. This approach reduces the need to manage pipelines or infrastructure and can offload analytical workloads from the source system. For example, if source data resides in an on-premises SQL Server database, you can create a SQL Server mirror in Fabric and analyze the latest available data there.
• Open Mirroring: This is an extension of mirroring for any data sources that are specific to your organization. Open Mirroring enables applications or partners to write changes directly into an open mirroring landing zone, after which Fabric converts and manages the data as Delta tables.
• Pipelines: are an option when a solution requires explicit data movement, multi-step orchestration, complex transformations, or integration across multiple sources.

The following diagram illustrates how mirroring and shortcuts complement Fabric compute experiences by either bringing data into Fabric or making externally stored data available without traditional ingestion.

Figure: Mirroring and shortcuts provide different approaches for making source data available to Fabric workloads.

Decision guide

If you are using Snowflake and/or Databricks in your organization and if you are deciding which option best fits your use case, the following guide compares the available approaches and highlights when each one is most appropriate.

Figure: Fabric integration options by source platform, data-movement pattern, and use case.

Integration recommendations

The following options may provide a starting point. The appropriate design depends on source support, data residency, freshness, transformation, governance, security, networking, cost, and operational requirements.

Figure: Recommended starting points for common Snowflake and Databricks integration scenarios.

User layer: AI Foundry and Copilot Studio with data agents

Making enterprise data accessible in Fabric is only the first step. Once that data is available through a governed integration pattern, organizations can build AI experiences that allow users and applications to interact with it using natural language.

Microsoft Fabric Data Agents allow users to interact with governed data using natural language and can generate and execute queries across supported Fabric experiences. Data Agents make it possible to gain insights directly from data without building an agent from scratch.

After creating a Data Agent, you can publish it to applications or other consumer experiences. As shown in the AI Agent Decision Tree, several consumer-layer options are available. This article focuses on two: Copilot Studio and Microsoft AI Foundry.

Copilot Studio

Copilot Studio is a low-code platform for building agents that combine generative AI with enterprise data and system actions. It is a practical option for employee or customer self-service, support automation, conversational access to Fabric data, and workflows where an agent needs to retrieve information or invoke an existing business process.

After publishing a Fabric Data Agent, you can connect it to Copilot Studio to build a custom agent that also uses other data sources. You can then publish the agent to Microsoft 365 experiences such as Teams. This option works well for common, out-of-the-box scenarios that a large language model can support without extensive customization.

Microsoft AI Foundry

Microsoft AI Foundry is where you would go when you need more control over how an AI application or agent is built and operated. It brings models, agents, tools, evaluation, and monitoring into one place, while still letting developers choose how much code and customization they want. In the context of Fabric, a Foundry agent can use a Fabric data agent as one of its tools, so it can work with governed enterprise data alongside other knowledge sources and business systems.

This option is well suited to use cases that require greater control over model behavior, orchestration, evaluation, and customization. Microsoft AI Foundry is typically best suited for professional developer scenarios.

Next steps

Microsoft Fabric provides multiple approaches for connecting existing data estates to analytics and AI workloads. Start by identifying whether your scenario requires data replication, virtualization, or explicit data movement, and then use the decision guide to choose the appropriate starting point.

To explore these capabilities in more detail:

• Learn how OneLake shortcuts make external data available to Fabric without traditional data movement.
• Explore Mirroring in Microsoft Fabric for supported databases and data platforms.
• Learn how Microsoft Fabric Data Factory pipelines support orchestration and data movement.
• Explore Fabric data agents for natural-language interaction with governed Fabric data.
• Learn how to connect a Fabric data agent to Copilot Studio or Microsoft AI Foundry.