Retirement of Fabric data agent integration in Copilot in Power BI
Nearly a year ago, we announced the integration between Fabric data agent and Copilot in Power BI, allowing users to access a Fabric data agent directly from Copilot in Power BI. This integration enabled users to explore report data and interact with data agents within the same workflow. When you asked a question about your data, Copilot worked with you to understand your topic of interest, then used that context to identify the right data agent, along with other data sources, to answer from. We are retiring this integration Beginning August 26, 2026, the integration between Copilot in Power BI and Fabric data agents will be retired. Copilot in Power BI will no longer connect directly to Fabric data agents. After that date, users will no longer be able to ask Copilot in Power BI questions that are answered through a Fabric data agent. This change does not affect the Fabric data agent experience itself. Fabric data agents remain available through other supported experiences and continue to provide access to the data and capabilities through those experiences. Why we are making this change The Copilot in Power BI integration was built on the OpenAI Assistant API. As that API is being retired, we are retiring this integration as well. Rather than investing in a replacement for this specific integration, we are focusing on supported experiences that continue to provide access to Fabric data agents today. focusing on supported experiences that continue to provide access to Fabric data agents today. Where you can continue to use Fabric data agents Fabric data agents remain available through different supported experiences across the Microsoft ecosystem and beyond, including: Directly in the Fabric data agent experience Microsoft Foundry Microsoft Copilot Studio Microsoft 365 Copilot A Model Context Protocol (MCP) server endpoint, which enables integration with your own supported apps and tools. The underlying Fabric data agent remains unchanged by this retirement. Security controls and permissions continue to be enforced in accordance with the configuration and capabilities of the experience being used, including your data sources, security rules such as row level security and column level security, and permissions. Planning your transition If you currently access Fabric data agents through Copilot in Power BI, consider transitioning to one of the supported experiences previously listed. The most appropriate option will depend on how your organization uses Fabric data agents today and the workflows you want to support. For example, organizations already using Microsoft 365 Copilot may choose to access data agents there, while organizations building custom experiences may find Microsoft Copilot Studio, Microsoft Foundry, or MCP-based integrations better aligned to their needs. Questions? Thank you for building with us and for your continued feedback. We remain committed to supporting Fabric data agents through supported experiences across the Microsoft ecosystem and beyond. If you have questions, please reach out and we will help you find the right fit.
Connectivity patterns in Microsoft Fabric: A guide for data integration workloads
This blog post focuses on connectivity options for Microsoft Fabric workloads that use Data Factory runtime components, including Dataflow Gen2, Fabric Data Pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models, and Power BI paginated reports. The guidance and networking considerations described in this article apply to the above data integration scenarios of Fabric. Workloads such as Notebooks, Spark Job Definitions (SJD), and other Spark-based experiences are not covered by this guidance. These workloads use the Fabric Managed Virtual Network (Managed VNet) for data access and therefore follow a different connectivity model and network architecture. Enterprise data rarely lives in a single location. It is often distributed across public cloud services, Azure virtual networks, on-premises environments, and software-as-a-service applications. Microsoft Fabric must have a supported network path to each data source before workloads can access it. The appropriate connectivity option depends primarily on the source network location and whether Fabric must cross a private network boundary. This guide will help you determine when to use a VNet data gateway, an on-premises data gateway, or a direct cloud connection for data integration scenarios of Fabric. A simple way to choose the right option is to start with one question set: Where does the data source live, and does Fabric need to cross a private network boundary to reach it? Why gateway choice matters The connectivity model determines how Fabric reaches data sources and can affect security, governance, operational overhead, and network architecture decisions. Before users can build semantic models, pipelines, reports, notebooks, or analytical experiences, the platform needs a reliable way to reach the data. A gateway acts as an intermediary between a supported Fabric workload and a data source. It establishes the required connectivity path, relays supported queries or data requests and returns results to the calling service. The exact data movement and processing behavior depends on the Fabric workload, connector, connection mode, and gateway type. Gateways provide secure connectivity to private data sources through outbound-only communication and encrypted data transfer, eliminating the need to expose internal systems to the public internet. In Microsoft Fabric, that connectivity decision can affect how securely Fabric reaches the source, whether infrastructure needs to be deployed or maintained, whether the connection can be shared across teams, and how well the pattern fits enterprise governance requirements. Selecting the right connectivity pattern early can help prevent architecture changes later. For example, a source protected by private endpoints may require a different approach than a publicly accessible SaaS application, while an on-premises SQL Server deployment often has different requirements than a cloud-to-cloud integration scenario. Option 1: VNet data gateway Use a VNet data gateway when a supported data source is reachable from an Azure virtual network and is not intended to be accessed through a public endpoint. The source might use a private endpoint, reside in a connected virtual network, or be reachable from Azure through an appropriately configured private network path, such as ExpressRoute. VNet data gateway provides a Microsoft-managed connectivity option for supported data sources that are reachable through an Azure virtual network. Organizations can enable private connectivity without deploying or maintaining gateway virtual machines, making this a good option when you need private network access without managing additional infrastructure. When to use it The data source is reachable from an Azure virtual network. The scenario requires private connectivity, such as access through a private endpoint or an ExpressRoute-connected network. Fabric workloads that need secure and scalable access to data sources enabling Dataflow Gen2, Data Pipelines, Copy Job, Mirroring, Semantic Models, and Paginated Reports to access enterprise data Your organization prefers Microsoft-managed gateway rather than deploying and maintaining gateway virtual machines. The required Fabric workload, connector, authentication method, and region are supported. The Azure virtual network has the required network configuration and available capacity. Key benefits Microsoft-managed infrastructure: Microsoft operates the gateway infrastructure, reducing the need to deploy and maintain gateway virtual machines. Private network reachability: Supported Fabric workloads can connect to sources reachable from the Azure virtual network. Network isolation: Data sources can remain behind private network boundaries instead of requiring public endpoints. Hybrid reachability: Sources connected to the virtual network through supported network paths, including ExpressRoute, can be reachable without deploying the gateway directly in the on-premises environment. Capacity management: Supported scaling capabilities can help accommodate changing workload demands while reducing manual infrastructure management. Centralized connectivity: Administrators can configure and govern shared connections for supported workloads and users Option 2: On-premises Data Gateway, standard mode The on-premises data gateway is customer-managed software that runs on a supported machine in a network that can reach the data source. The gateway can be installed on an on-premises server or on a supported virtual machine, depending on the organization’s network design and operational requirements. Standard mode supports shared connectivity across approved users, connections, and workloads. Your organization is responsible for deploying, updating, monitoring, and maintaining the gateway host. When to use it The data source resides within an on-premises environment or a private network that is not directly accessible from Microsoft cloud services. You're able to provision and manage the required gateway infrastructure, including virtual machines, software updates, monitoring, and lifecycle maintenance. Multiple users or workloads need access, and the gateway should be centrally managed. You need enterprise-grade sharing and governance across Fabric, Power BI, Power Apps, Power Automate, Logic Apps, or Azure Analysis Services. Key Benefits Securely access on-premises and private-network data sources from Microsoft Fabric. Reuse existing network, firewall, and security investments without exposing data sources to the public internet. Centrally manage and govern connectivity for multiple users, teams, and workloads. Support hybrid and multi-cloud integration scenarios from a single gateway platform. Improve reliability and scalability through gateway clustering and high-availability deployments. Accelerate Fabric adoption by leveraging existing infrastructure and operational processes. Option 3: Cloud connection with no gateway Use a cloud connection with no gateway when the source is already cloud-based and publicly accessible. In this scenario, Fabric can connect directly to the service without traversing a private networking layer. Fabric can connect directly to the service using the supported connector and authentication method. This is often the simplest connectivity path. If the source is a public SaaS application, cloud API, or cloud data service that does not require access through a private network, then a gateway may not be needed. When to use it The source is fully cloud-based and publicly reachable. There is no private endpoint or private network boundary. Direct SaaS or cloud-to-cloud connectivity is supported. You do not need gateway infrastructure or runtime management. Common connectivity scenarios The following examples illustrate common Microsoft Fabric connectivity patterns and can help simplify gateway selection. Depending on the network architecture, some on-premises data sources may be reachable through either On-premises Data Gateway or VNet data gateway. Azure SQL Database with a private endpoint: If Azure SQL Database is accessible only through a private endpoint or a virtual network, use a VNet data gateway. This allows Fabric workloads to securely access the data source without requiring public network access. Azure Storage account secured through virtual network rules: When a storage account is protected by Azure virtual network restrictions and cannot be accessed through a public endpoint, a VNet data gateway is typically the appropriate choice. On-premises data sources connected to Azure through ExpressRoute: Organizations often use Azure ExpressRoute to extend their on-premises network into Azure. When a supported data source remains on-premises but is reachable from an Azure virtual network through ExpressRoute, a VNet data gateway can provide private connectivity from Fabric without requiring customer-managed gateway infrastructure. This can simplify operations while maintaining private connectivity between Microsoft Fabric and the data source. SQL Server hosted in an on-premises datacenter: If the data source resides within a corporate datacenter or private network and is not reachable from Azure virtual networks, use On-premises Data Gateway (standard mode) to provide shared, enterprise-grade connectivity. Line-of-business applications hosted behind a corporate firewall: Applications such as SAP HANA, Oracle, or other supported data sources that are accessible only from the corporate network generally require On-premises Data Gateway (standard mode). Cloud services with public endpoints: For supported cloud services such as Salesforce, Azure SQL Database (public endpoint), Azure Data Lake Storage Gen2 (public endpoint), or other publicly accessible SaaS and PaaS offerings, Fabric can often connect directly without requiring a gateway. Although these examples represent common deployment patterns, always verify connector support, authentication requirements, networking configuration, regional availability, and workload compatibility when designing your connectivity architecture. Final takeaway When planning Microsoft Fabric connectivity, start with the location of the data source and determine whether Fabric must traverse a private network boundary. That single decision typically determines whether a VNet data gateway, an On-premises Data Gateway, or a direct cloud connection is the appropriate choice. Use VNet data gateway when you need managed gateway to securely connect Microsoft Fabric workloads to data sources protected by Azure Virtual Networks, private endpoints, or on-premises environments that are connected to Azure through ExpressRoute. Use On-premises Data Gateway standard mode for self-hosted shared enterprise access to on-premises or private firewall sources. Use a cloud connection without a gateway when the supported cloud data source is reachable directly through its public endpoint and the scenario does not require a private network path. By using this decision flow, teams can design cleaner, more secure, and easier-to-manage connectivity patterns for Microsoft Fabric. Next steps Use the decision flow in this article to identify the connectivity model that best aligns with your data source location, network architecture, and operational requirements. Before implementation, review the supported workloads, connectors, authentication methods, and regional availability for your specific scenario. To learn more, explore: Microsoft Fabric documentation VNet data gateway documentation On-premises data gateway documentation Microsoft Fabric security documentation By selecting the appropriate connectivity option early in your architecture design, you can simplify deployment, improve security, and reduce ongoing operational overhead while enabling reliable access to enterprise data. For additional guidance, review the Microsoft Fabric connectivity and gateway documentation to confirm support for your workloads, connectors, authentication methods, and regions.
Microsoft recognized as a Leader in The Forrester Wave™: Data Lakehouses
For years, organizations have invested in data platforms to understand what happened across their business. Dashboards, reports, and KPIs are now table stakes. But as AI becomes central to how organizations operate, the bar for the data lakehouse is getting much higher. The next generation of applications and agents needs governed access to every kind of data: structured, semi-structured, and unstructured; batch, streaming, and real-time—working together on one open foundation. When that data remains spread across fragmented systems, teams are left reconciling copies, duplicating governance, and stitching together context before they can create value. Today, we're proud to share that Microsoft has been recognized as a Leader in The Forrester Wave™: Data Lakehouses, Q3 2026. In the report, Forrester describes Microsoft Fabric as “a strong fit for enterprises seeking a unified, AI-enabled lakehouse platform integrated with the Microsoft ecosystem.” We believe this recognition reflects the bold vision behind Microsoft Fabric and Microsoft OneLake: helping organizations eliminate the integration tax of fragmented data estates by bringing data, analytics, governance, and AI together on one open lakehouse foundation. Fabric: A unified foundation for the AI-era lakehouse The Forrester report frames the modern lakehouse as more than a system of record for analytics. As agentic AI systems begin to reason, plan, and act on enterprise data, the lakehouse is becoming the operational foundation where intelligence is grounded and activated in real time. Microsoft Fabric was built for this shift. With OneLake, Fabric gives organizations a single, governed data lake and one SaaS platform where data teams, analysts, developers, and business users can work from the same trusted foundation. Forrester notes that Microsoft’s approach emphasizes deep integration across Power BI, Copilot, Microsoft 365, OneLake, databases, and AI services—helping unify analytics, operational, and AI workloads within a single ecosystem. Forrester also highlights Microsoft’s “bold vision of a unified, AI-powered, open data platform that brings together analytics, data engineering, business intelligence, and operational data.” Furthermore, they add that “innovations such as OneLake shortcuts, mirroring, AI-powered transformations, and cross-cloud interoperability support this vision by reducing silos and simplifying access to distributed data.” One open foundation for data and analytics OneLake is the governed data lake at the heart of Fabric, designed to unify your entire multi‑cloud data estate. It connects data across clouds and on‑premises systems using zero‑copy, zero‑ETL access, so teams work from a single, governed copy of data. With native support for open formats like Delta Lake and Iceberg, this data remains accessible from any analytics engine or platform, including Microsoft Fabric, Snowflake, and Azure Databricks. Once data is connected or stored in OneLake, the OneLake catalog helps secure, govern, and organize it into a logical data mesh, making trusted data easy for everyone to discover and use. Govern once, across every engine Security, identity, lineage, and governance are built into Fabric rather than bolted on tool by tool. State of the art OneLake security can define object-, row-, and column-level controls once and enforce them consistently across Spark, SQL, KQL, Power BI, Copilot, and third-party engines through OneLake security APIs. The OneLake catalog centralizes sensitivity labels, classification, and end-to-end lineage, helping organizations simplify governance while giving users trusted access to the data they need. Every workload on one lakehouse Fabric brings relational, real-time, analytical, document, and vector workloads into one platform experience on OneLake. Spark powers data engineering with the Native Spark Execution Engine in Microsoft Fabric, which accelerates workloads by running much of the execution in highly optimized native C++ code with vectorized processing, while preserving the same Spark APIs, notebooks, and DataFrame code users already know. With the native execution engine, Spark in Fabric delivers up to 6x faster performance than open-source Apache Spark, helping improve price performance by completing the same workloads with less compute and lower costs. Additionally, the warehouse engine and lakehouse SQL endpoint serve interactive queries over the same Delta tables; Real-Time Intelligence supports streaming and event-driven scenarios; and Power BI queries OneLake directly through Direct Lake without importing or moving data. AI native to the data platform Fabric’s integration with Copilot and agents enable natural language analytics and intelligent automation at scale. Vector embeddings can sit alongside structured data for AI retrieval, so teams can build analytics, AI, and applications on one governed copy of data. Instead of moving data to each workload, organizations can bring more workloads and more AI-powered experiences to the same open lakehouse. Why organizations choose Fabric Customers are seeing real impact from using Fabric: less duplication, cleaner governance, faster development, and a simpler path from data to AI. At the foundation is a common pattern: organizations are consolidating fragmented data estates onto a single governed lakehouse. London Stock Exchange Group (LSEG), a partner to the world's leading financial institutions, set out to simplify a complex, fragmented data landscape and give its customers a consistent, unified experience. Using Fabric, LSEG is building a unified data platform that consolidated 30 systems, 1,200 datasets, and 33 petabytes of data, accelerating product development, improving data quality, and advancing AI readiness. Product development timelines have moved from years to months, delivering faster, cleaner data to everyone from global firms to individual traders. "When you need to pull data together across disparate sources that are in different formats and varying levels of modernisation and maturity, it makes it difficult to react to market demand quickly. We knew it would be far more efficient to bring everything into a single, modern platform. It would mean we could run the organisation leaner and react to market demand faster.” Dave Byrne, Group Head of Data Platforms at LSEG Once data is unified, organizations can apply governance and analytics at enterprise scale. UNC Health standardized its enterprise data estate on Fabric, creating a single, governed lakehouse foundation for clinical analytics, operations, population health, and research. Fabric powers UNC Health’s AI solutions, which reduced care-gap chart review time by nearly 50% and provides the governed data foundation for a secure research environment supporting 25 active studies. That same foundation also creates new opportunities for AI-driven innovation. Eastman, a global specialty materials company, adopted Fabric to modernize its legacy data architecture and create a unified, governed lakehouse foundation for analytics and AI. Using OneLake shortcuts and data mirroring, Eastman shares data across domains without unnecessary duplication, ingested roughly one billion rows from eight systems, and established a scalable platform for analytics, machine learning, and AI-powered applications. “We operate in a lot of markets that are fundamentally different from one another. Being able to aggregate all this loose, unstructured data into something that’s actionable is really helping our commercial organization build better strategies for the year ahead.” —Andrew Ervin, Manager of Generative AI, Eastman Taken together, these examples illustrate the evolution of the modern lakehouse: first unifying data, then governing it consistently, and ultimately turning it into a foundation for AI-powered innovation. This is the shift that many organizations are making as they prepare for the next generation of applications and agents. Strategic takeaways for enterprise leaders Three shifts stand out for leaders preparing their organizations for the next generation of AI: The lakehouse is now the default foundation for AI. Agents and AI applications need governed access across every data type; not siloed systems stitched together after the fact. Openness prevents lock-in. Open table formats and bi-directional interoperability help organizations unify their estate without walking away from the tools and platforms they already run. Reducing duplication changes the economics. Bringing workloads to a shared, governed foundation helps organizations simplify operations, strengthen consistency, and accelerate innovation. As organizations prepare for the next generation of AI-powered applications and agents, the need for a unified, open, and governed data foundation will only grow. Microsoft Fabric was built to bring data, analytics, governance, and AI together on that foundation, and we’re excited to keep innovating alongside our customers. Forrester’s recognition reinforces what we’ve believed from the start: the organizations that succeed in the AI era will be those that eliminate fragmentation, simplify governance, and build on one open lakehouse. Learn more Read the complimentary report. Explore Microsoft OneLake and Microsoft’s vision of an open data lake ecosystem. Join us at the next Fabric + SQL Community Conference in Barcelona to hear directly from our product and teams and community members. Statement from Forrester Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester's objectivity here.The future of conversational analytics in Fabric
What if you could ask questions about your business data in plain language, and get trusted answers wherever you work? Discover how Fabric IQ, Power BI, Microsoft 365 Copilot, and Fabric data agents are bringing the full breadth of conversational analytics into the flow of work, turning governed business context into insights and action.
From Lakehouse to boardroom: Analytics and AI for real insights
If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. An end-to-end look at what we’re shipping in Fabric Analytics, what we are prioritizing, and real AI value. Every enterprise I speak with wants the same thing from AI: measurable business value. That value doesn’t emerge from isolated tools or experimental notebooks. It shows up where business users already work—inside Microsoft 365, where decisions are made every day in Excel, Teams, Outlook, and Copilot. The real challenge is in building an analytics stack that can carry data end-to-end: from ingestion and performance critical transformation, through semantic modeling, and all the way to AI experiences that operate inside business workflows without rewrites, resets, or runaway costs. That end-to-end responsibility is what guides our work across Azure Data Analytics. Our goal is simple but demanding deliver a complete analytics platform by making data ready and usable for AI, preserving its meaning across every layer, and delivering insight fast, always with a relentless focus on price × performance. We are also entering an era where the fastest path to insight often starts with an agent and natural language commands. If you’re the kind of developer or power analyst who wants to move faster, isn’t afraid to mix and match tools, lean on GitHub Copilot CLI, this post is for you. By the end, you’ll see how natural language and agents let you interact directly with your data so you can get answers faster than traditional workflows allow. Customers like Bajaj Finserv, which operates a broad financial services portfolio, have adopted Fabric as its unified analytics platform and this shift has changed how analytics impacts their business. “Moving to Microsoft Fabric helped consolidate our data foundation into one governed, observable platform. Instead of managing fragmentation, my team now focuses on building reliable patterns that scale with deeply integrated capabilities like Fabric Data Warehouse and Spark. The shift reduced costs and operational friction, and restored confidence.” Nagaraju Gutlapalli, Head of Data Engineering, Bajaj Finserv At FabCon, we’re shipping major updates across the entire Fabric Analytics stack—faster data processing, a stronger and more scalable SQL warehouse, a semantic layer that makes AI trustworthy, and agents that put governed answers directly inside Microsoft 365. Contents Data Engineering Data Warehouse Power BI AI & Data Agents The end-to-end vision New developer tools: Agent Skills for Fabric Get started at FabCon Atlanta Data Engineering Speed, scale, and the relentless pursuit of best performance at the lowest cost If you are building an AI-ready analytics platform, everything starts with data engineering. And the single most important attribute of a data engineering platform is price × performance. If data processing is slow or expensive, every downstream layer suffers models lag, insights stall, and AI becomes impractical at scale. That’s why Fabric Data Engineering is designed to push performance as far as possible on open formats like Delta and Parquet, without forcing code changes. The backbone of Fabric Data Engineering is Apache Spark, significantly enriched with efforts we are often offering to the open-source community. Our Native Execution Engine has been delivering significantly lower latency for Parquet and Delta workloads under vectorized execution. But we did not stop there. Let me share what we have done to push Fabric Spark into a category of its own. Performance for every format The Native Execution engine for Fabric Data Engineering provides you with a 6x performance boost over OSS Spark, with no code changes necessary. Furthermore, Z-order and Liquid Clustering optimizations are fully supported for both reads and writes. Parallel snapshot loading dramatically reduces Delta metadata read time for tables with many files. If you have wide Delta tables with thousands of partitions, you will experience the impact immediately. Figure 1: Price performance of Native execution engine for Fabric Data Engineering compared against OSS Spark. Runtime and compute ergonomics Runtime 2.0 brings Spark 4.0 and Delta Lake 4.0 to Fabric in preview. Spark 4.0 includes significant query planning improvements, and Delta Lake 4.0 introduces features like variant data types. The new Resource Profiles capability offers simplified user experience for expressing the intent of your job and sets you up with the recommended set of Spark Configurations. We want your start up times to always be instantaneous, so we are in the process of rolling out Custom Live Pools to preview. Workspace admins can create dedicated warm compute pools with any node size and count. You express intent, and Fabric handles the configuration and startup latency. Figure 2: The new Resource Profiles capability sets you up with the recommended set of Spark Configurations. Materialized Lake Views (MLVs) are an exciting new Fabric capability enabling customers to build and chain together pre-computed views in their lakehouse, update them incrementally, and apply data quality constraints. MLVs are now generally available, making it easier to implement medallion architecture on Fabric and make your pipelines production-ready with broader clause support for incremental refresh, flexibility of supporting multi-schedules in a single lakehouse, in-place updates, PySpark authoring, and stronger data quality enforcement. Figure 3: Materialized lake views make it easier to implement medallion architecture on Fabric and make your pipelines production ready. Spark ODBC and ADO.NET drivers for Spark (Preview) with JDBC drivers reach general availability. Multiple authentication modes are supported including Azure AD, service principals, and managed identities. AI-assisted engineering The new and improved Copilot in Data Engineering and Data Science experience (Preview) is context-aware by default, understands your notebooks, data, and environment from the moment you start. With built-in awareness and focused context control, Copilot helps teams write, understand, debug, and optimize notebooks faster, while gaining performance insights as they build. It can reach across Fabric and reference the workspace for additional context. The VS Code experience is also improved through the Data Engineering extension. Data Science and Machine Learning are core to modern data engineering, and we are making significant progress in this area. AutoML in Fabric (Generally Available) providing automated model selection, feature engineering, and hyperparameter tuning directly into the Fabric Data Science experience, tightly integrated with notebooks, experiments, and MLflow tracking to reduce time from data to production-ready models. We are also announcing Multimodal AI Functions (Preview), extending Fabric’s built-in AI Functions beyond text to support images and PDFs, and enabling AI powered transformations over unstructured data directly from pandas or PySpark workflows. Data Warehouse Enterprise architecture that scales with you A data warehouse is where raw data becomes business-ready data. And in an AI world, the warehouse needs to do more than store and serve it to be fast enough for interactive workloads, intelligent enough to maintain itself, and flexible enough to support both human analysts and AI agents. Predictable performance at scale Custom SQL Pools (Preview), giving you user-defined, customizable, isolated pools of compute resources. You can create separate pools for ETL, reporting, and ad-hoc queries, with physical resource isolation so concurrent queries do not interfere with each other. The architecture separates control flow from physical execution: a single SQL frontend handles control flow and distributed query processing, while routing queries to the appropriate pool based on your configuration. One workspace, multiple pools, complete isolation. Figure 4: Custom SQL Pools offer predictable performance at scale. Freshness, without operational tax The new metadata sync for SQL analytics endpoints addresses one of the most common customer complaints: data staleness. We are delivering a 30-second SLO for data freshness. Once delta logs for a data change are available in storage, you can query it via the SQL analytics endpoint within 30 seconds, regardless of whether the endpoint was previously deactivated. This feature will roll out to preview in the next few weeks. In addition, two more features are becoming generally available. Proactive Statistics Refresh frontloads query optimizer statistics maintenance immediately after data changes, so your queries are not paying the cost of stale stats at execution time. Incremental Statistics Refresh updates statistics for large tables incrementally rather than re-sampling entire columns, dramatically reducing maintenance overhead for tables with billions of rows. These are the kinds of under-the-hood optimizations that separate a warehouse that works at demo scale from one that works at enterprise scale. AI and action where the data lives We are adding built-in AI functions directly to T-SQL: AI_ANALYZE_SENTIMENT, AI_CLASSIFY, AI_EXTRACT, AI_GENERATE_RESPONSE, AI_SUMMARIZE, AI_TRANSLATE, and AI_FIX_GRAMMAR. SQL developers can now invoke AI capabilities without leaving the language they already know, without standing up separate services, and without moving data out of the warehouse. Figure 5: Built-in AI functions are now directly available in T-SQL. Additionally, you can create intelligent, configurable alerts and follow-up actions, triggered by results of your queries. If your key business metrics are out of the ordinary, send a Teams message to the right folks; if your data pipeline resulted in extreme data skew, automatically fire off an email to the ops team. Figure 6: Create rules on SQL query results to detect data issues, monitor KPIs, and automatically trigger alerts or Fabric workflows. Strengthening our fundamentals The MERGE command is now GA. A single, standardized statement for INSERT, UPDATE, and DELETE operation, the workhorse of incremental data loading patterns. If you are building medallion architectures (and you should be), MERGE is the verb that moves data from Silver to Gold cleanly and efficiently. DacFx integration in web experiences brings consistent, Git-based schema management to Fabric Warehouses. Export and import warehouse definitions such as database projects, capture and review schema changes using a single DacFx-based model, and deploy with predictable, repeatable behavior across dev/test/prod. Even more powerful: cross-warehouse reference support enables dependency-aware development across multiple warehouses. Build Bronze, Silver, and Gold layers across warehouses without broken references — Git commits and pipelines execute in the correct order based on cross-warehouse dependencies. We are enhancing Migration Assistant with live connectivity to source systems like Azure Synapse. No DACPAC extraction required, just connect, and the assistant fetches object metadata, translates it to Fabric DW-compatible schemas, and applies it. Start faster, reduce complexity, and reduce risk. A new Monitoring UX provides a one-stop shop for live and completed queries with performance comparison across executions. Query Insights now exposes full query text, SQL pool names per query, and live running queries. SQL Pool Insights adds a dedicated view for understanding whether your SQL Pool is under pressure. Figure 7: A new Monitoring UX provides a one-stop shop for live and completed queries with performance comparison across executions. Finally, several critical enterprise features are now Generally Available – SQL Audit Logs for Fabric Data Warehouse and SQL Endpoint, Outbound Access Protection, COPY INTO and OPENROWSET, and SSMS 22.5.0 integration. Power BI The semantic layer that makes AI trustworthy You probably know this already: AI is only as good as the semantic context it operates on. You can put the most advanced language model in front of raw tables, and it will sound confident, right up until it is wrong. What turns AI from a guessing machine into a reasoning system is a well‑curated semantic model that encodes business meaning: measures, relationships, hierarchies, time intelligence, and definitions that reflect how your organization works. None of this works if semantic models are an afterthought. This is why Power BI is foundational. Because (once you strip away aspirational demos) at scale, no other BI platform combines semantic expressiveness, performance, and installed base in the way Power BI does. Customers chose Power BI because it can represent real business complexity without compromise, and because it is the fastest BI engine in the world. Our responsibility is clear: to carry your investments forward into the era of AI, without forcing rewrites, ports, or semantic resets, so the meaning you have already built continues to power both human analysis and AI reasoning. Translytical Task Flows (Generally Available) Translytical Task Flows (Generally Available), now enables users to take action directly from Power BI reports, add, update, or delete data, or trigger workflows in other systems, without leaving the report. This transforms Power BI from a read-only analytics surface into an operational tool. See an anomaly in a report? Fix the underlying data right there. Report Copilot for mobile Ask questions about your data using voice or text in the Power BI mobile app and get instant answers or visuals. A data assistant in your pocket, literally. This is Copilot meeting users where they already are, not requiring them to context-switch to a separate tool. Figure 8: Ask questions about your data using voice or text in the Power BI mobile app and get instant answers or visuals. TMDL View on the web View and edit your data model’s code directly in the Power BI web interface using Tabular Model Definition Language (TMDL). This gives developers and data modelers more control, more transparency, and the ability to make precise changes without roundtripping through external tools. Figure 9: TMDL View allows you to view and edit your data model’s code directly in the Power BI web interface. Direct Lake over OneLake (Generally Available) Direct Lake over native Delta tables is now Generally Available, bringing a fully streamlined path for Power BI to query OneLake data in its original Delta format without duplication or import steps. This GA release delivers near real‑time analytics by keeping semantic models directly connected to lake data, removing refresh delays and enabling faster, more efficient access to large‑scale datasets. Table Visual: Custom Totals and Modern Defaults Customize totals in table visuals and enjoy cleaner, more consistent default styles. These are the kinds of polish improvements that add up across an organization with thousands of reports. AI & Data Agents Every Office user, chatting with their data This is where the work across the stack comes together. All the work we do in data engineering, warehousing, and semantic modeling has a single ultimate purpose: making data accessible to everyone in the organization, not just analysts and engineers. Figure 10: Fabric Data Agents can reason over data in OneLake, support deeper analysis, and deliver insights. Fabric Data Agents (Generally Available) Data Agents are the last mile in the analytics pipeline. They sit on top of your semantic models and OneLake data, understand the context encoded in your Power BI measures and relationships, and expose that intelligence to all users through natural language conversations in M365 Copilot. When agents are grounded in governed semantic models, AI stops guessing, and starts reasoning with the same definitions the business already trusts. With Data Agents in Microsoft Fabric now generally available, users can seamlessly build and interact with agents across a wide variety of data sources, including Lakehouse, Warehouse, Semantic Models, Eventhouse, SQL Databases, etc. Configuration is highly flexible, allowing you to tailor each agent’s behavior with both agent-level and data source–specific instructions, as well as custom example queries. Sharing and publishing Data Agents within Microsoft Fabric is straightforward, enabling easy operationalization and collaboration across teams. This release also brings robust lifecycle management features to the platform, including diagnostics, Git integration, and deployment pipelines as part of Microsoft Fabric’s Application Lifecycle Management (ALM) suite. These tools empower you to troubleshoot, manage, and evolve your Data Agents with confidence, supporting a broad range of scenarios and use cases. Building on these advancements, we are also excited to introduce the preview of several new capabilities and experiences in public preview: Security and governance in Data Agents Recent enhancements to Fabric Data Agents focus on strengthening security and governance. The integration with Purview enables comprehensive auditing, eDiscovery, data lifecycle management, communications compliance, and classification by capturing prompt and response telemetry and user context, ensuring enterprise-grade protection and compliance. Additionally, outbound access protection is being expanded for Data Agents, helping organizations prevent sensitive data exfiltration and meet stringent security requirements. Together, these updates offer better tools for monitoring, controlling, and safeguarding data interactions when using data agents in Fabric. Source enhancements in Data Agents We are expanding Fabric Data Agent’s data source capabilities with significant improvements. By introducing Graph as a data source, we allow Fabric users to model complex relationships in their data and leverage these Graphs in data agents for AI-powered insights. Additionally, support for KQL User Defined Functions (UDFs) enables richer, more optimized querying for Eventhouse and other KQL-backed sources, translating natural-language questions into efficient, secure queries. These enhancements make data agents more versatile and powerful, delivering faster analytics and broader scenario coverage for end users. Figure 11: Fabric data agents now support Graph as a data source. The end-to-end vision From Lakehouse to boardroom Step back and look at what we have built. A single data pipeline that flows like this: Spark ingests and transforms raw data at speed: vectorized execution, instant-start pools, auto-tuned configurations, all optimized for price×performance over open Delta and Parquet formats on OneLake. Fabric Data Warehouse then makes data enterprise-ready: workload-isolated SQL pools, 30-second freshness SLOs, AI functions built into T-SQL, and Git-based CI/CD for production-grade deployments. Power BI adds the semantic layer: the measures, relationships, hierarchies, and business context that turn raw numbers into organizational knowledge. This is the layer that makes AI trustworthy. Data Agents take that semantic knowledge and put it in the hands of every user through M365 Copilot: natural language, no training required, governed by Purview, secured by outbound access protection. Every layer runs on OneLake, over open data formats. No data movement between layers. No proprietary storage. One estate, governed consistently, is accessible from any compute engine. One security model. Not merely an architectural diagram, nor a single-engine posing as many tools, this is a running production system, based on proven opensource and Microsoft-built engines, and serving thousands of organizations today. The design principle that cuts across all of it is price × performance. Not a tradeoff between price OR performance, but the product of both. Every feature we ship is evaluated against the question: does this make customers faster AND more economical? Native Execution Engine, Resource Profiles, Custom Live Pools, Proactive Statistics, Custom SQL Pools: these are expressions of a single obsession our team has with providing value. Each layer can be adopted independently, but the economics improve materially when they are used together. New developer tools: Agent Skills for Fabric Last, but certainly not least: Agent Skills for Fabric in GitHub Copilot CLI I want to close with something a bit different, something for the developers who live in the terminal, but also for power analysts who want to get to insights as quickly as possible. We are announcing Agent Skills for Fabric in GitHub Copilot CLI, an open-source set of purpose-built plugins that allow you to use natural language to harness Microsoft Fabric, end-to-end. GitHub Copilot CLI is GitHub Copilot for your terminal: a command line tool that lets you talk to your shell in natural language and has Copilot generate, explain, and run commands or code directly from the CLI. With Agent Skills for Fabric, your natural language commands now wield the power of the Fabric engines. You can start with something as simple as “Document my workspace” (don’t forget to mention the name!), or something more complex such as “Demo NYC Taxi Trip data is available here https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page. Create a Fabric medallion architecture project for all trips in 2019” These are specialized skills: for Spark authoring and consumption, SQL warehouse authoring and consumption, Eventhouse authoring and consumption, Power BI semantic model interaction, and end-to-end medallion architecture orchestration, each with deep domain knowledge about Fabric patterns, best practices, and operational workflows. This points to the future of the developer experience for data platforms. To learn more, check out the Agent Skills for Fabric GitHub repo. Figure 12: Windows PowerShell terminal displaying a prompt ready for user input. Get started at FabCon Atlanta This is a pivotal moment for Microsoft Fabric and for every organization building its data and AI strategy. The announcements we are making this week represent a shift in capability across every layer of the analytics stack. I encourage you to: Attend the sessions — from deep-dive workshops on Data Agents to core-note sessions on Data Engineering, Warehousing, Power BI and the future of AI in Fabric—there’s something for everyone! Try the features — Custom Live Pools, Custom SQL Pools, Data Agents (Generally Available) and Agent Skills for Fabric and many more are available now. Connect with our experts — our engineers are here and eager to hear your feedback. Come find us at the Ask the Experts booths in the expo hall. The foundation for AI is not a model — it is your data curated, governed, and made accessible across the organization. With Fabric, we are building a single, production-ready analytics system that turns trusted data into action, whether in a notebook, a SQL query, a Power BI report, or a conversation in M365 Copilot. That’s what it takes to move from lakehouse to boardroom—and that is exactly what we are delivering!Securing the Power Query connector ecosystem in Fabric
Reliable analytics starts with reliable connectivity. We understand that when moving your data, data security is of the utmost concern; we are committed to providing the most secure, cutting-edge data connectivity solutions; enabling you to have the confidence that your data is safe, secure, and reliable. As Microsoft Fabric continues to evolve into an end-to-end analytics platform, we are making focused investments to ensure Microsoft delivers enterprise-ready connectivity across the most widely used data platforms. Over the past year, customers have been clear about what they expect from connectivity: strong security posture, predictable behavior, and long-term support. In response, we have been modernizing how data connectors are built, shipped, and supported—placing a deliberate emphasis on securing the connector supply chain and clarifying the connector lifecycle. Securing the connector supply chain Microsoft is committed to securing the connector supply chain. That’s why Microsoft is now bringing all connectors in-house. This commitment to directly providing our customers with the most secure and reliable connectors decreases long-term security and operational risk for our valued enterprise customers. Our approach moving forward is clear: to build and maintain Microsoft-owned, in-house connectors to: Provide the most secure, stable connectors for our customers. Ensure the highest quality connectors, equipped to most quickly enable new features, and capabilities as the connector evolves. Improve Microsoft security, compliance, and operational standards end-to-end. This shift aligns with Microsoft’s broader security commitments and ensures that connectivity is treated as a first-class platform capability within Fabric, solely managed by Microsoft. A clear connector lifecycle for Power BI’s data connectors To help customers understand why we are strengthening our connector supply chain and bringing more connectors in-house, we want to provide clear visibility into the connector lifecycle. Our goal is to ensure a predictable, secure experience, while providing industry-leading, innovative connectors, as we continue modernizing our connector portfolio. Microsoft connectors follow a structured lifecycle designed to prioritize security, reliability, and transparency. They generally, progress through the following stages: Preview – Early access to new or modernized connectors so customers can evaluate functionality and use case application. General Availability (GA) – Fully supported, production ready connectors that meet Microsoft’s inhouse quality, reliability, and security standards, with ongoing updates and versioning. Transparent Migration – As we introduce improved connector implementations — including updated security models, protocol changes, and platform upgrades — we work to ensure transparent and supported migration. This ensures customers’ current production workloads continue to run smoothly, while customers transition their production workloads from legacy to new connector versions. Retirement – Legacy versions are retired once more secure and reliable alternatives are broadly available. This ensures customers remain protected and benefit from continuous security and performance improvements. This lifecycle, backed by structured versioning and clear upgrade paths, ensures customers can confidently adopt the latest innovations while minimizing disruption and maintaining the highest levels of security and reliability. Recent V2 connectors reaching general (Generally Available) September 2025, several Microsoft V2 connectors (Generally Available) reflecting this modern, security first approach to connectivity. Recently shipped connectors (Generally Available) Snowflake (V2 connector) ADBC-based Power Query connector, establishing the foundation for modern, Microsoft owned, connectivity at scale. To learn more, refer to the Snowflake documentation. Google BigQuery (V2 connector) A fully supported connector following multi-semester‑ investment in stability, performance, and enterprise readiness. To learn more, refer to the Google BigQuery documentation Vertica & IBM Netezza (Bring Your Own Driver) Our “Bring Your Own Driver” experience for Vertica and Netezza; this enables customers to implement their own driver through OPDG for these sources. To learn more, refer to the IBM Netezza documentation and the Vertica documentation. Amazon Redshift (V2 connector) With the collaboration of Amazon Redshift, this connector supports our overarching strategy in secure connectivity across the major cloud data warehouses with a consistent, enterprise-ready connectivity experience. To learn more, refer to the Redshift documentation. Together, these releases represent a meaningful step toward consistent, secure, and predictable connectivity across Power BI, Dataflows, and Microsoft Fabric. Shaping what comes next with Fabric Ideas Connectivity continues to evolve, and customer input plays a critical role in where we invest next. We rely on Ideas to understand demand for new connectors, enhancements to existing ones, and emerging platform requirements. If there is a connector you need—or an existing one you want to see improved—we welcome your feedback via Ideas. Customer feedback submitted through Ideas directly influences our prioritization and roadmap decisions. Looking ahead Our goal is straightforward: deliver connectivity that enterprises can trust. By securing the connector supply chain, clarifying the connector lifecycle, and continuing to invest in modern, in-house Power Query connectors, we are building a foundation that will scale with Microsoft Fabric for years to come. We’re excited to continue this journey with our customers.
