Create purpose-built custom visuals in Real-Time Dashboards with Copilot (Preview)
Real-Time Dashboards include built-in visuals for common monitoring and analysis scenarios. However, operational decisions do not always fit a standard chart. You may need to combine several signals, use a domain-specific layout, or present information differently for a particular workflow or audience. Custom visuals with Copilot, now in preview, help you create a dashboard experience around the operational question you need to answer. With custom visuals, you can describe the operational view you need in natural language. Copilot creates the supporting KQL query and HTML-based visualization directly in the dashboard, helping you move from an operational question to a tailored visual without first adapting the scenario to a predefined chart. Move beyond predefined chart types A standard chart starts with a visual type such as a line, bar, or pie chart. You then shape the query and formatting to fit that structure. This model works well when the question maps naturally to an established chart. Operational questions don't always fit that model. You might need a visual that combines several signals, uses a domain-specific layout, or presents status in a form that matches how your team works. Building that experience outside the dashboard can require front-end development and separate deployment and maintenance processes. Custom visuals begin with the outcome instead. Describe the operational question and the visual you want, and Copilot uses the selected database context to generate both the KQL query and an HTML-based visualization. The result is added directly to the dashboard as a new tile. Example: Turn venue metrics into an operational view Consider a venue operations dashboard that tracks wait times and ingress volume across several entrances. Standard KPI and chart visuals can show those measures individually, but an operator may need to understand how conditions differ across the venue. With a custom visual, the dashboard author can describe that operational view directly: arrange entrances spatially around the venue, show the current wait time and ingress volume for each entrance, and use color to highlight congestion. Copilot can then generate a visual design around that scenario. The result is not simply another way to plot the same data. It presents the information in a form designed around the operational question: Where is congestion building, and which entrance needs attention? Create a custom visual Start from a Real-Time Dashboard that you can edit, and that has its data sources to create a custom visual, open a Real-Time Dashboard that you can edit and confirm that its data sources are configured for custom visuals. In Editing mode, select Add visual > Describe a visual, enter your prompt, and submit it. Copilot adds the visual to the current dashboard page and generates the connected KQL query and HTML-based visualization Review the first result as a starting point. The quality of the visual depends in part on how clearly the prompt communicates the question, the data to use, and the intended presentation. Write a focused prompt A useful prompt gives Copilot enough context to choose the relevant data and design a visual that answers a specific question. Include the following details: The operational question: Explain the decision or condition that the visual should support. Measures: Name the values to calculate or compare, such as event count, latency, volume, or service state. Dimensions: Identify how to group or organize the results, such as location, service, category, or severity. Time range: Define the period that matters, such as the last hour or the last 24 hours. Presentation: Describe the visual form when you have a specific operational layout in mind. Interactions: Describe how viewers should explore the visual, such as displaying additional details or using controls to change what is shown. For example, you can ask Copilot to: Show the current operational status of each venue entrance. Display average wait time and ingress volume for each entrance and use color to make congestion immediately visible. Arrange the entrances spatially around the venue so operators can quickly identify where attention is needed. Create a storm monitoring view that positions storm events by latitude and longitude. Size each event based on severity and use color to distinguish warning levels. Show additional event details when a viewer explores an event. Create a service health board that shows each service and its dependencies as connected nodes. Use color to distinguish healthy, degraded, and critical services, and make critical services visually prominent so operators can quickly identify where investigation is needed. These prompts do more than name a chart. They describe the relationship between the data and the way a viewer should interpret it. You can make them more precise by adding the relevant measures, status rules, categories, or time window from your data. Review and refine the result Creating a custom visual is an iterative authoring experience. After Copilot creates the tile, review whether the visual answers the intended question and whether the generated query selects and aggregates the expected data. To make changes, select the Edit icon on the tile. In tile edit mode, you can review the query and the visual, then use the Copilot pane to refine either one. Follow-up prompts can clarify the original request without requiring you to start over. For example, you might narrow the time range, change the grouping, emphasize a service state, or adjust how the information is presented. Continue until the visual communicates the operational state clearly. Then select Apply, resize, or reposition the tile, and save the dashboard. Switch to viewing mode to confirm that the saved visual renders as expected in the experience your dashboard viewers use. This review step is important for AI-assisted authoring. Validate the generated query and visuals against your data and operational requirements. Clear labels, appropriate aggregation, and a focused visual hierarchy help viewers understand the result quickly. Next steps Start with an operational question that does not fit a standard chart. Describe the experience you need and use Copilot to create a first version that you can review and refine before sharing the dashboard. This approach helps you turn specialized monitoring needs into tailored operational views without building and maintaining a separate front-end experience. Learn how to configure the required identity and cloud connection, create a tile, write a focused prompt, and refine the result in Create a custom visual in a Real-Time Dashboard. Explore the built-in options in the Real-Time Dashboard visual gallery. Review formatting options for standard tiles in Customize Real-Time Dashboard visuals.
Retiring the Fabric data agent custom tool in Microsoft Foundry: move to Fabric IQ
In March 2025, we announced that agents in Microsoft Foundry could use Fabric data agents to answer questions about data in Microsoft Fabric. In the earlier integration, you connected to a data agent by adding it as a custom tool. For details, refer to Consume a data agent in Microsoft Foundry. What’s changing We are deprecating the earlier custom-connection integration. Starting 11/6/2026, that integration will no longer be supported. If your Foundry agents use a Fabric data agent as a custom tool, you must migrate them before that date. The replacement integration (Preview) uses the Fabric IQ (OneLake Catalog) tool, which makes your data available to agents and applications. In the Foundry portal, you can use this tool to add a published Fabric data agent to a Foundry agent. For configuration steps, refer to Consume Fabric data agent from Microsoft Foundry via Fabric IQ. Capabilities with the new integration The replacement integration changes how you find and connect Fabric data agents: Select accessible published data agents from the catalog. In the Foundry portal, the OneLake Catalog shows the published data agents available to you by name, so the connection workflow does not require you to enter a workspace ID or an artifact ID. Connect more than one data agent. A Foundry agent can call multiple data agents, such as separate agents for sales data and customer support data. The earlier custom-connection integration only supported one Fabric data agent. Connect through a Model Context Protocol (MCP) endpoint. MCP is an open standard for how an agent calls a tool. Each selected Fabric data agent is presented to the Foundry agent as a tool through a MCP endpoint. Coming soon, when a data agent answers a question, its response will also include the query it used to generate the answer. What you need to do If any of your Foundry agents use a Fabric data agent as a custom tool, complete the following steps before 11/6/2026: In Microsoft Fabric, make sure to publish your Fabric data agent with a rich and detailed description. Open the agent in the Microsoft Foundry portal. In the Tools section, add the Fabric IQ (OneLake Catalog) tool, and then select your data agent from the catalog. Update the Foundry agent's instructions. Name each data agent and describe the types of questions it should handle. Remove the earlier custom tool and then save the Foundry agent. Test the Foundry agent with representative questions for each connected data agent. If you connect data agents in code, update your implementation to use the Fabric IQ tool. For samples in Python, C#, and JavaScript, refer to Connect agents to Microsoft Fabric with Fabric IQ. Guides to migrate from Fabric Data Agent to Fabric IQ tool Option 1: Migrate in Foundry Portal Navigate to Foundry Portal and open the Tools Catalog, select “Fabric IQ (OneLake Catalog)”. . In the OneLake catalog, filter by “Data agent” type. Select any data agent you want to use, and you are ready to go. Provide instructions to your Foundry agent about how to use Fabric data agent. . Option 2: Migrate in SDK/Rest API After you publish the Fabric data agent, open its Settings and go to the Model Context Protocol tab. This tab shows: Data agent MCP server name MCP server URL (copy this value; you can use in every client) Data agent MCP tool name MCP server tool description Once you get the data agent MCP server URL, proceed with the following steps: Step 1: Get an access token az account get-access-token --resource https://management.azure.com --query accessToken -o tsv Step 2: Create a Foundry connection to the Fabric data agent A connection stores the Fabric data agent endpoint and how to sign in to it. Your agent uses this connection to reach Fabric. Replace each value in angle brackets, then run the request: curl --request PUT \ --url 'https://management.azure.com/subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name>?api-version=2025-04-01-preview' \ --header 'Authorization: Bearer <access-token-from-step-1>' \ --header 'Content-Type: application/json' \ --data '{ "type": "Microsoft.MachineLearningServices/workspaces/connections", "properties": { "authType": "UserEntraToken", "group": "AzureAI", "category": "RemoteTool", "target": "<fabric-data-agent-mcp-endpoint>", "audience": "https://api.fabric.microsoft.com/.default", "isSharedToAll": true, "sharedUserList": [], "UseCustomConnector": false, "Credentials": { "ClientId": "fake" }, "metadata": { "ApiType": "Azure" } } }' Main field capabilities: Field Value What it means authType UserEntraToken The agent calls Fabric as the signed in user, with that user's Microsoft Entra token. category RemoteTool The connection points to a remote tool, in this case an MCP endpoint. target Your MCP endpoint The address of your Fabric data agent. audience https://api.fabric.microsoft.com/.default The token is issued for the Fabric API. isSharedToAll true Every user in the Foundry project can use the connection. Credentials.ClientId fake Keep this value as shown. The response includes an id field. This is the full resource ID of the connection. Save it for step 4. It looks like this: /subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name> Step 3: Install the Python packages pip install "azure-ai-projects>=2.2.0" azure-identity Step 4: Set the environment variables Variable Where to find it FOUNDRY_PROJECT_ENDPOINT The Overview page of your Foundry project. FOUNDRY_MODEL_NAME The deployment name of your model in your Foundry project. FABRIC_IQ_PROJECT_CONNECTION_ID The full connection resource ID from step 2. Use the full ID, not only the connection name. export FOUNDRY_PROJECT_ENDPOINT="<your-project-endpoint>" export FOUNDRY_MODEL_NAME="<your-model-deployment-name>" export FABRIC_IQ_PROJECT_CONNECTION_ID="<your-connection-resource-id>" Step 5: Create an agent that uses the Fabric IQ tool and ask it a question This script creates a prompt agent with the Fabric IQ tool, sends it one question, prints the answer, and then deletes the agent. import os from azure.identity import DefaultAzureCredential from azure.ai.projects import AIProjectClient from azure.ai.projects.models import PromptAgentDefinition, FabricIQPreviewTool endpoint = os.environ["FOUNDRY_PROJECT_ENDPOINT"] with ( # Signs in with your Azure command line interface account (from az login). DefaultAzureCredential() as credential, AIProjectClient(endpoint=endpoint, credential=credential) as project_client, project_client.get_openai_client() as openai_client, ): # 1. Define the Fabric IQ tool. It uses the connection you created in step 2. fabric_iq_tool = FabricIQPreviewTool( project_connection_id=os.environ["FABRIC_IQ_PROJECT_CONNECTION_ID"], require_approval="never", # The agent calls the tool without asking you first. ) # 2. Create the agent with your model, its instructions, and the Fabric IQ tool. agent = project_client.agents.create_version( agent_name="MyAgent", definition=PromptAgentDefinition( model=os.environ["FOUNDRY_MODEL_NAME"], instructions="Use the available Fabric IQ tools to answer questions and perform tasks.", tools=[fabric_iq_tool], ), ) print(f"Agent created (id: {agent.id}, name: {agent.name}, version: {agent.version})") # 3. Ask the agent a question. Change this to a question about your own data. user_input = "Which customers placed orders above $10,000 last quarter?" response = openai_client.responses.create( input=user_input, extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}}, ) print(f"Agent response: {response.output_text}") # 4. Delete this agent version so unused versions don't build up in your project. project_client.agents.delete_version(agent_name=agent.name, agent_version=agent.version) print("Agent deleted") Finally, run the script. python fabric_iq_agent.py Learn more and share feedback We recommend that you move to Fabric IQ as soon as you can. We look forward to improving this integration, and we’d like to hear your feedback. Join the community discussion to share feedback and report issues. For more information, see these articles: Consume Fabric data agent from Microsoft Foundry via Fabric IQ Connect agents to Microsoft Fabric with Fabric IQ
Incrementally migrate and re-migrate database objects with Migration Assistant for Fabric Warehouse (Preview)
Migrate database objects to Microsoft Fabric in phases without creating a new Warehouse for every run. Start with one business domain, add another when it is ready, or revisit an object after its source definition changes. You can also build on an existing Warehouse instead of replacing it. Incremental migration for Microsoft Fabric Data Warehouse (Preview) lets you move workloads in manageable phases while keeping control of the destination. Select the objects required for the current workload, add more objects in later runs, and resolve naming conflicts when an incoming object already exists. The process migrates object definitions; it does not continuously synchronize changed rows. You can start with an empty Warehouse, continue a previous migration, or use an existing Warehouse that was not created through migration. This flexibility lets teams preserve completed work while adding the next approved scope. It also supports deliberate consolidation into the Fabric destinations that match your architecture. Choose the objects that belong in each migration Enterprise migration plans often span several teams, applications, and business domains. Those groups do not always need to move together. Incremental migration lets you define the scope of each run. Instead of including every source object, select the objects needed for the workload you are moving. For example, start with the schemas, tables, and views required by one business domain. Review the translated definitions and validate the dependent workload before expanding the scope. In a later run, return to the same Warehouse and add the next approved set of objects. In the destination Warehouse, open the Migration tab and select Get more objects. Provide the source connection or upload a supported source input, and then select Choose more objects to migrate to define the next set. Figure: Use Get more objects to start another migration run from the destination Warehouse. Figure: Select source objects and review dependencies and naming conflicts before migration. Before you start the run, review the complete object list populated in the selection dialog. The list flags naming conflicts and adds direct dependencies for selected objects. Confirm that every included object is necessary for the workload you intend to migrate. Filter source objects to show all objects, objects with naming conflicts, or objects without naming conflicts. Identify objects whose names already exist in the destination through warning indicators. Review each selected object’s direct dependencies before you start the migration. Migration Assistant includes those dependencies by default, so the final scope can contain more objects than you initially selected. Review the source, destination, selected objects, and included dependencies in the summary. Confirm that every object belongs in the current scope and that naming conflicts have an owner. The Migration Assistant guide for connecting to a source system describes the workflow. Build on an empty or existing warehouse The destination does not have to come from an earlier migration or a specific migration mode. Choose the destination based on the workload, ownership model, security boundary, and naming plan. The following starting points are supported. An empty Warehouse: Begin with a destination you have prepared and migrate the first set of objects into it. A previously migrated Warehouse: Add more objects or revisit selected objects from an earlier run. A Warehouse that was not created through migration: Bring source objects into a Warehouse that already contains work created through other means. You do not need to create another Warehouse just because you are starting another migration run. Reusing a destination can reduce unnecessary duplication and keep related objects together. Confirm, however, that the shared destination fits the workload and data-isolation requirements. Re-migrate objects with control Migration work often requires revisiting an earlier decision. A source definition can change after the first run, or a translated object might need correction after validation. Re-migration lets you return to that object without treating the entire source as a new migration. When an incoming object's name already exists in the destination, Migration Assistant identifies a naming conflict. Objects without naming conflicts can be created immediately. Conflicting objects remain pending and are not created or replaced until you explicitly choose how to resolve each conflict. For each conflict, compare the SQL definitions side by side: the existing definition on the left and the incoming translated definition on the right. Review the full definition, not only the highlighted difference, because connected changes can affect downstream objects. Then choose the action that fits the object. Keep existing: Retain the destination's current definition and discard the incoming translated definition. Keep incoming: Replace the existing definition with the incoming translated definition, confirming the action when prompted. Rename incoming: Create the incoming object under a different name while retaining the existing object. Conflict handling makes re-migration an explicit decision. You can preserve work already completed in Fabric, accept a revised source definition, or keep both definitions under different names. Record the chosen action so that workload owners understand which definition is active. Figure: Compare existing and incoming definitions before resolving a naming conflict. Replacing an object changes its definition in the destination and may require you to reload data or revalidate dependent workloads. Before you replace a table, view, or procedure, identify the objects and processes that use it and plan the required follow-up work. For detailed behavior, refer to Resolve conflicts and fix objects. Consolidate your data estate Incremental migration lets you move selected objects from supported SQL Server databases, Azure Synapse Analytics dedicated SQL pools, or Teradata databases into one or more Fabric Warehouses. A separate destination Warehouse is not required for every source database or migration run. The destination design should still reflect workload ownership, security, naming, and data-isolation requirements. This approach supports several consolidation patterns. Choose a pattern only after confirming that the workloads can share the same operational and security boundaries. Common uses are listed below. Consolidate objects from multiple databases on the same source platform. Bring together selected objects from different supported source platforms. Expand the same Warehouse as additional databases and workloads are ready to migrate. As you add objects, conflict handling helps you manage names already present in the destination. Compare existing and incoming definitions, then keep the existing object, replace it with the incoming definition, or rename the incoming object. This decision determines which definition becomes part of the consolidated Warehouse. Consolidating destinations does not automatically reconcile definitions or combine table data. Review dependencies, naming conventions, permissions, ownership, and data-loading requirements before each run. These checks help the consolidated Warehouse reflect the intended architecture rather than an accidental collection of objects. Keep object migration and data loading distinct In this preview, incremental migration means selecting, adding, or revisiting database object definitions across separate migration runs. It covers object selection, translation, dependency handling, and definition conflicts, but it does not continuously synchronize changed rows. After migrating the required definitions and resolving conflicts, plan the associated data movement. Migration Assistant can integrate with a copy job in Data Factory for Microsoft Fabric to copy data into the destination. Treat that data movement as a separate activity with its own schedule, monitoring, and validation. Validate each selected workload before expanding the migration scope. Verify translated definitions, dependency completeness, conflict decisions, permissions, and the queries or reports that depend on the migrated objects. When replacing a table definition, include the required data reload and downstream validation in the plan. Keeping object migration and data loading distinct makes each run easier to review. The team can state which definitions move, which existing objects change, and what data work follows. That separation also makes failures easier to isolate and rerun. Next steps Reduce migration risk by starting with a small, representative workload: identify its boundary, choose the destination Warehouse, migrate the required objects, and validate the result before expanding the scope. For prerequisites and supported workflows, review the Migration Assistant for Fabric Data Warehouse overview, and then follow either the source-connection migration guide or the file-based migration guide.Microsoft & Snowflake’s Commitment to Apache Ossie
If you haven't already, check out FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents for a complete look at all of our FabCon Europe announcements across Fabric and Microsoft Databases. Advancing an open, interoperable semantic foundation for AI-powered analytics Today, Microsoft is pleased to affirm our commitment to Apache Ossie (incubating), a community-led effort to establish a vendor-neutral standard for exchanging semantic metadata across analytics, AI, and BI platforms. This has been a close collaboration with Snowflake, who helped found Ossie. We have heard loud and clear that customers want to enable platform-agnostic agentic experiences. Shared semantic context must be defined once and reused across platforms, enabling agentic consumption at scale, maximizing the reach of AI-powered analytics, and empowering users to leverage the best agent for the job. Power BI semantic models are key enablers of AI-powered analysis, providing humans and AI agents with governed semantic context to answer data questions quickly and confidently. Power BI semantic models have more than 38 million monthly active users and are adopted by 94% of Fortune 500 companies. Microsoft was also recognized as a Leader and Outperformer in the GigaOm’s radar for semantic layers & metric stores in 2025. We’re now bringing this wealth of experience to Apache Ossie, and we are excited to work with Snowflake and other partners to help make the project successful. Why Apache Ossie matters Until now, semantic definitions were often recreated across platforms, introducing complexity, inconsistency, and management overhead. Apache Ossie addresses this with a common specification that tools can read and write. Its goal is straightforward but consequential: define a semantic layer once and make it portable across the data and AI ecosystem, while preserving semantic meaning and governance for agentic consumption. Collaboration with Snowflake Snowflake and Microsoft serve many of the same customers, but customers don't want to choose between ecosystems. They want their data and analytics investments to work together. That makes interoperability between, for example, Snowflake Semantic Views and Power BI semantic models a shared responsibility. This layers on top of the integration work we have already done with Snowflake for writing Iceberg tables from Snowflake to OneLake, Mirrored Databases from Snowflake, using Iceberg tables with OneLake, Catalog Integration for OneLake, Power Query Snowflake connector and much more. As discussed in the Snowflake blog post and the message below from Carl Perry, VP of Analytics at Snowflake, our collaboration is currently focused on using Apache Ossie as a vehicle for cross-platform semantic-layer conversion without moving or duplicating the underlying data. Looking ahead, we’re committed to advancing the open standard by building on our deep expertise in semantic modeling by, including helping establish DAX as an Ossie-recognized query language. We also plan to help advance Ossie support for ontologies so customers can extend the business logic in semantic models beyond agentic analysis and into platform-agnostic operational intelligence. Ultimately our goal is simple: enable customers to define once, and reuse anywhere. Today, we are highlighting the following new integration scenario: converting an Ossie document into both a Snowflake Semantic View and a Power BI semantic model. This enables customers to define shared semantic context once, then reuse it across Snowflake and Fabric while retaining the agentic experiences and capabilities of each platform. Refer to Apache Ossie Microsoft Converter for more information. Building together We look forward to working with the Apache community, Snowflake, and others across the industry to create a more open and connected future for AI-powered analytics, delivering more choice and flexibility for customers. Get involved: Visit the Apache Ossie project website and repository to explore the specification and community contribution channels. Share your thoughts and feedback with us. Apache Ossie is undergoing incubation at the Apache Software Foundation. Incubation indicates that the project is working toward the governance, infrastructure, and community practices expected of established Apache projects.
Simplify Teradata migrations with Fabric Migration Assistant (Preview)
Migrating an enterprise Teradata estate to Microsoft Fabric can require extensive manual work across database objects, SQL and BTEQ code, dependencies, and operational processes. Fabric Migration Assistant helps reduce that effort so teams can focus their review on the objects and workflows that need attention. Fabric Migration Assistant for Data Warehouse now supports Teradata sources in preview. It converts eligible Teradata metadata and code to Fabric-compatible T-SQL, deploys eligible destination definitions, and flags scripts that need review or remediation, reducing the manual effort required to prepare a migration. You can choose which objects to migrate, review the translated code, and focus remediation on exceptions instead of manually translating every eligible object. Migration Assistant does not move the associated data; you load data in the following step of the migration flow. Define a migration scope you can validate Reduce migration risk by starting with a representative set of interdependent objects from one workload or business process. Keeping the related tables, views, procedures, functions, and macros together lets you evaluate the translated result as a working unit. A focused scope makes it easier to distinguish among three outcomes: Translation: The source definition was converted to Fabric-compatible T-SQL. Deployment: The translated definition was created successfully in the destination warehouse. Validation: The migrated workload produces the expected behavior and results. Translate Teradata metadata into Fabric-compatible T-SQL Package your Teradata .sql and .bteq files into a ZIP archive, including the object definitions and dependencies needed for the selected scope. From the Fabric workspace, open Migrate and select Teradata (Preview) under Migrate to a warehouse. The guided experience lets you upload the archive, choose the objects in scope, and confirm the destination before migration begins. Migration Assistant translates and creates eligible definitions for: Tables Views Stored procedures SQL functions Macros, which translate into stored procedures After the run, review migrated objects to see their status and translation details. This review helps you identify datatype and SQL changes that require validation before you treat successful object creation as a completed migration. Use the file-based Migration Assistant guide for the upload, object-selection, and review workflow. Focus remediation where it's needed Teradata and Fabric Data Warehouse don't have a one-to-one mapping for every construct. Some definitions translate directly; others need a different implementation. Teradata macros translate into stored procedures, while volatile tables map to local temporary tables. Review the maintained Teradata SQL translation reference for object mappings, data types, BTEQ behavior, and constructs that need redesign. Migration Assistant groups scripts that could not be translated or deployed under Objects to fix. For each object, the source definition, translation comments, and error details help you determine whether the issue requires a syntax correction or a broader change to workload behavior. If Copilot is available and enabled in your environment, Fix query errors can suggest a correction. Treat the suggestion as a starting point: compare it with the source definition and error details, revise it as needed, and run the script to validate the result before creating the object. Before accepting a corrected object, confirm that it preserves the intended workload behavior by comparing parameters, joins, filters, and transaction boundaries with the source logic. Bring BTEQ business logic into Fabric workflows BTEQ scripts can combine SQL with control flow, session management, imports, exports, and operational logic. Migrating those scripts requires attention to the surrounding workflow, not just the SQL statements. Migration Assistant translated eligible SQL and supported BTEQ elements into stored procedures. Review the generated procedures, then rebuild imports, exports, orchestration, and external operations with the appropriate Fabric capabilities. Different parts of a BTEQ workload can use different Fabric capabilities: SQL and supported control flow: Review the translated stored procedure. Data imports and exports: Use the appropriate loading or export capability, including COPY INTO or pipeline copy activities. Scheduling, orchestration, and external operations: Recreate the required behavior through Fabric pipelines or other appropriate execution environments. Translation doesn't automatically reproduce the entire operational environment. Validate parameters, error paths, sequencing, and external dependencies alongside the translated SQL. The objective is to preserve the business behavior you need while choosing suitable Fabric implementations. Figure: Animated GIF —Migration Assistant for Teradata migration showcasing metadata translation flow. Choose how to move the data Metadata migration establishes the destination definitions in Microsoft Fabric Data Warehouse. Data movement loads the associated rows after the required table definitions are in place. Choose the method that fits each workload: Copy job: Use the guided transfer from Migration Assistant's Copy data step. Connect to Teradata, select tables, review mappings, and choose the copy mode. A full copy can establish the initial dataset; incremental copies are an option when the source configuration supports them. Staged files and COPY INTO: For large historical transfers, unload Teradata data to Azure Data Lake Storage Gen2 and load the staged files into Fabric Data Warehouse with COPY INTO. Fabric pipelines: Use pipelines when the migration needs multi-step orchestration, transformations, branching, or custom recovery logic. To learn more, refer to Migration methods for Teradata to Fabric Data Warehouse for data movement options and guidance on replacing Teradata loading utilities. Validate the migrated workload Run representative queries and compare the results with the Teradata workload. Validate row counts, aggregates, filters, joins, null handling, and the date and numeric behavior that affects the business process - not merely whether each object exists in the destination. Include both expected paths and failure paths in the test scope. For procedures and translated BTEQ logic, verify parameter handling, transaction boundaries, retry behavior, and the sequence of dependent operations. Next steps Use Plan a migration from Teradata to Fabric Data Warehouse to define the scope and validation approach. Review Translate Teradata SQL for Fabric Data Warehouse for object mappings and use Migration methods for Teradata to Fabric Data Warehouse to choose the data-movement method.
From mixed events to real-time action: Fabric Eventstreams Q3 2026
Coauthor: Arindam Chatterjee Fabric Eventstreams makes it easy to connect to streaming sources, transform the ingested events and route them to destinations across Microsoft Fabric. But building real-time systems also requires teams to understand the events in motion, enriching them with business context, detecting and responding to any issues on time, and securely managing their streams across environments. That broader experience is the story behind this quarter’s updates. Eventstreams is expanding beyond connectivity and data movement to provide more of the capabilities teams need to work with streaming data after it arrives, while it is still in motion. With these expanded capabilities, users can now: Connect to more managed sources and extend Eventstreams with custom connectors. Capture change feeds from more operational databases. Explore and process multiple event types in a single Eventstream. Enrich streaming events with contextual data before processing and routing. Monitor processing health, diagnose problems, and act faster. Deploy with workspace-scoped networking and reusable configuration. Connect managed and custom streaming sources Eventstream added generally available managed connectors for SAP Datasphere, Cribl, Solace PubSub+, and MQTT, extending native connectivity across enterprise applications, observability pipelines, event meshes, and IoT brokers. For these common scenarios, teams can use managed connectors instead of writing and hosting connector code. Managed connectors cover a growing range of common sources. But many organizations also need to connect proprietary applications, partner products, and internal platforms. Custom Stream Connector (Preview) lets organizations bring compatible Kafka Connect source connectors into Fabric when a native connector is unavailable. Teams can manage versions, publish connectors internally or through a partner, and make them discoverable in Real-Time hub. This approach extends managed Fabric pipelines to proprietary applications, partner products, and internal platforms while allowing independent software vendors to retain control of their code and licensing. What shipped: SAP Datasphere connector (Generally Available), Cribl connector (Generally Available), Solace PubSub+ connector (Generally Available), MQTT connector (Generally Available), Custom Stream Connector (Preview). Bring operational changes into the stream Orders, inventory updates, account changes, and application state already live in operational databases. Capturing those changes is only the first step. Teams must also operate connectors, recover from failures, handle schema changes, and scale the pipeline. This complex operational work makes many CDC-based solutions difficult to sustain. Two connectors reaching general availability this quarter move more of that burden into Eventstream. The Mirrored Database Change Feed connector consumes row-level inserts, updates, and deletes from change-feed-enabled mirrored databases. The MongoDB CDC connector supports MongoDB Atlas, cloud-hosted, and self-managed deployments. Both bring database changes into Eventstream's managed processing model, ready for the same DeltaFlow transformations available to other CDC sources. What shipped: Mirrored Database Change Feed connector (Generally Available), MongoDB CDC connector (Generally Available) Understand every event shape Streaming data rarely arrives in one consistent shape. A source may carry messages from multiple device types, application payloads may evolve, and teams may combine sources to improve utilization and reduce cost. Treating every payload as a union of every possible field makes exploration harder and creates long fragile transformations. Schema Registry and Event Schema Sets (Generally Available) provide reusable contracts for streaming data. Teams can define Avro schemas, group related schemas, retain earlier versions, compare changes, and discover schemas across Fabric workspaces. Schema-aware Eventstreams (Preview) lets one eventstream understand and process multiple event types. Events with registered schemas, along with change feeds from supported operational databases, are recognized automatically. For unschematized payloads, users can classify events with a field such as deviceType or entityType. A redesigned data preview makes it easier to inspect each event: Browse and inspect nested JSON structures View event headers and metadata along with the actual payload Download selected events What shipped: Schema Registry and Event Schema Sets (Generally Available), Schema-aware Eventstreams (Preview). Add business context in flight Live events often contain only a device ID, customer ID, or product code. Without the surrounding business context, downstream systems cannot make an informed decision until a separate batch process enriches the data once it reaches an analytical store. Reference Data with Delta Table (Preview) brings that enrichment into Eventstream. A live event can join with reference data in a Lakehouse or warehouse table, including shortcut-backed Delta tables. No-code INNER and LEFT OUTER joins cover common patterns, while the SQL experience supports more complex logic. The event gains business meaning before it is routed, not after. What shipped: Reference Data with Delta table (Preview) Detect issues and act faster A streaming pipeline can appear to be running even when a node falls behind, events arrive outside the expected time window, or a destination rejects processed values. A top-level running state is not enough to diagnose these conditions. This quarter adds a more complete operating loop around each Eventstream. Workspace Monitoring helps teams observe throughput, backlog, watermark delay, errors, and node health. Processing logs and editor validation help diagnose malformed input, query failures, type-conversion errors, event-time policy violations, recovery events, and destination-access problems. Teams can act by creating and managing Activator rules without leaving Eventstream, then optimize capacity by routing Capacity Operation Events through Eventstream for operation-level analysis, alerting, and governance. What shipped: Workspace Monitoring for Eventstream (Preview), Workspace Monitoring diagnostic-log support (Preview), Activator rule management in Eventstream (Generally Available), Capacity Operation Events source (Preview). Secure and deploy eventstreams consistently Enterprise streaming workloads often need private connectivity, environment-specific configuration, and explicit control over where data can flow. Workspace-level Private Link (Preview) for Eventstream lets administrators apply private inbound connectivity to selected Fabric workspaces instead of imposing the same network posture across the tenant. Variable Library support (Preview) keeps environment-specific connections, item references, parameters, and value sets separate from pipeline logic. Teams can carry one Eventstream across development, test, and production without embedding each environment's values in the definition. These capabilities build on existing support for private and on-premises sources, workspace identity, custom certificate authorities, mutual TLS, and outbound access protection. What shipped: Workspace-level Private Link for Eventstream (Preview), Variable Library support for Eventstream (Preview). What this quarter adds up to Together, these updates create a more complete path from incoming events to business action. Teams can understand mixed payloads, enrich events while they are moving, bring in operational changes, connect managed or custom sources, diagnose processing problems, and carry the same Eventstream safely across environments. This quarter also brings an early glimpse of how Eventstreams can connect streaming and batch data movement more closely. Copy Job support for Eventstreams (Preview) enables an Eventstream to be used as either a source or destination in the Copy Job experience, creating an initial bridge between the two. The experience starts in Copy Job today, but it points toward more connected data movement experiences across Fabric. Fabric Eventstreams is expanding beyond ingestion to help teams shape, enrich, monitor, and govern real-time data as it moves from source to business action. Resources Generally Available Schema Registry in Fabric Real-Time Intelligence Add Mirrored Database Change Feed source to an eventstream Add MongoDB CDC source to an eventstream Add an SAP Datasphere source to an eventstream Add Cribl source to an eventstream Add Solace PubSub+ as source to an eventstream MQTT Source in Fabric Eventstream Add a Fabric Activator Destination to an Eventstream Preview Schema-Aware Eventstreams Overview (Preview) Enrich Events with Reference Data in Fabric Eventstreams Add a custom stream connector to an eventstream Eventstream Workspace Monitoring Overview (preview) Fabric Capacity Operation Source in Fabric Eventstream Secure inbound connections with Tenant and Workspace Private Links Variable Library Integration with Eventstreams For the full release roundup, including items outside this post's scope, see the August 2026 Fabric Feature Summary and the September 2026 Fabric Feature Summary. Get started Start with the capability above that most closely matches what your team needs, then follow its documentation links to try the corresponding Eventstream feature(s) in your workspace. Found a gap, a bug, or a scenario these features do not cover? Share it through Fabric Ideas or directly with us on the Eventstream PM team. Your feedback helps shape what comes next.
More expressive graph analysis: GQL improvements in Microsoft Fabric Graph
Coauthors: Idris Motiwala, and Justin Fine January–August 2026 updates expand how users find, inspect, compose, and analyze connections. Organizations use graph data to understand how information moves between systems, how services depend on one another, how conversations develop, and how people or organizations relate. Graph Query Language (GQL) in Microsoft Fabric Graph helps users explore and analyze those connections with standardized query patterns. From January through August 2026, new GQL capabilities made it easier to control traversals, inspect paths, compose multistage queries, summarize connected data, and work with complex values. These improvements help analysts express more graph questions in a single query and give developers finer control over query behavior. The following sections explain where each capability is useful and show the associated syntax. Find and control paths Shortest paths with ANY SHORTEST When several paths connect two entities, many applications need one shortest path rather than every possible path. ANY SHORTEST makes that intent explicit. This is useful for dependency analysis, recommendations, network routing, and investigations where fewer intermediate steps are preferred. MATCH ANY SHORTEST ({id: 1})->{,2}(d) RETURN d.id AS dst Quantified edge patterns Quantified edge patterns repeat a complete relationship pattern and can apply conditions to intermediate nodes. In the following example, each repeated step requires the source person to use Chrome. This gives developers more control than repeating only an edge pattern. MATCH p=(a:Person {id: 987})((x)-[k:knows]->() WHERE x.browserUsed = 'Chrome'){2}(b:Person) FOR n IN NODES(p) WITH OFFSET off RETURN n.browserUsed ORDER BY a.id, b.id, off LIMIT 12 Complete path modes Path modes define whether a traversal can revisit nodes or edges. WALK permits repetition. TRAIL prevents repeated edges. SIMPLE prevents repeated interior nodes. ACYCLIC prevents any repeated node. DIFFERENT EDGES prevent one edge from satisfying more than one edge variable in the match. These choices help query results reflect the meaning of a route, hierarchy, or dependency chain. MATCH WALK (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) RETURN p.firstName AS name MATCH TRAIL (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) RETURN p.firstName AS name MATCH SIMPLE (x)->{2}(y) RETURN COUNT(*) AS path_count MATCH ACYCLIC (x:`node` {id: 1})->(y)->(z) RETURN x.id, y.id, z.id ORDER BY x.id, y.id, z.id MATCH DIFFERENT EDGES (p:Person {name: 'Keanu Reeves'})-[e:ACTED_IN]->(m:Movie) RETURN m.title AS movie Unbounded variable-length path patterns Variable-length paths previously required a maximum hop count. Unbounded quantifiers allow the graph structure to determine the traversal depth when no meaningful fixed limit exists. The example follows one or more relationships, while ACYCLIC prevents the traversal from visiting the same node twice. Unbounded refers to the path expression, not unlimited compute, so use selective starting points and test performance with representative graph density. MATCH ACYCLIC ()-[]->{1,}() RETURN COUNT(*) AS total Inspect paths and graph elements NODES, EDGES, and INNER_NODES These functions expose the contents of a matched path. NODES returns all nodes in the path, EDGES returns all relationships in the path, and INNER_NODES returns the intermediate nodes without the endpoints. Applications can use these results to explain lineage, dependencies, and investigative findings instead of returning only a destination. MATCH p=({id: 1})-[]->{0,4}(z) RETURN NODES(p) AS res_nodes, INNER_NODES(p) AS res_inner_nodes ORDER BY z.id ELEMENT_ID ELEMENT_ID returns the identity of a graph element. It is useful when an application must compare, track, or reference a specific node or edge independently of its business properties. MATCH (x) RETURN ELEMENT_ID(x) AS vid, x AS actual_id ORDER BY x.id LIMIT 5 SOURCE and DESTINATION SOURCE and DESTINATION identify the endpoints of an edge. This makes directional checks and edge-centric analysis easier, especially when a query starts from a relationship rather than a node. MATCH (x)-[e]->() RETURN x.id, SOURCE(e).id AS s ORDER BY e.src, e.dst LIMIT 10 MATCH ()-[e]->(x) RETURN false IN COLLECT_LIST(x = DESTINATION(e)) AS no Compose larger queries NEXT NEXT passes the output of one query stage into the next, allowing analysts to express a multistep question in a single query. For example, they can calculate a measure, filter the result, traverse another relationship, and summarize the final result without moving intermediate data into application code. MATCH (m:Message)-[:hasCreator]-(p:Person) RETURN p, AVG(m.length) AS avg_msg_length GROUP BY p NEXT FILTER avg_msg_length > 100u MATCH (p)-[:knows]->(:Person) RETURN avg_msg_length, COUNT(*) AS connections GROUP BY p, avg_msg_length EXISTS subqueries EXISTS answers a yes-no question about another graph pattern. It can filter rows or participate inside an aggregate without requiring the outer query to return the matching details. MATCH (x) WHERE EXISTS { MATCH (y) WHERE y.id = 5 RETURN y } RETURN x.id AS xid ORDER BY xid MATCH (x) RETURN COUNT(*) FILTER ( WHERE EXISTS { MATCH (x)-[]->(y) RETURN y } ) AS count_with_out CALL subqueries CALL runs a contained query for each current outer result. In the example, it calculates each node’s outgoing degree and returns that value with the node identifier, keeping the intermediate calculation contained within the query. MATCH (x) CALL { MATCH (x)-[e]->(y) RETURN COUNT(e) AS out_degree } RETURN x.id AS xid, out_degree ORDER BY xid OPTIONAL CALL OPTIONAL CALL preserves the outer row when the contained query has no match. This supports enrichment scenarios where related information is useful but not required. MATCH (x {id: 1}) OPTIONAL CALL { MATCH (y)-[]->(x) RETURN y.id AS yid } RETURN x.id AS xid, yid ORDER BY yid UNION DISTINCT UNION DISTINCT combines compatible result sets and removes duplicate rows. It complements UNION ALL, which preserves duplicates, so the query can choose the correct set behavior. MATCH () LIMIT 3 RETURN 42 AS x UNION MATCH () LIMIT 3 RETURN 100u AS x Summarize connected data Filtered and paged aggregates Filtered aggregates calculate a summary over a selected subset. Paging controls such as LIMIT can be applied within the aggregate, giving developers precise control over which values contribute to the result. MATCH (m:Movie) RETURN COUNT(*) FILTER (WHERE m.released < 1980 LIMIT 10) AS filtered_count Nested aggregations Nested aggregation supports layered questions, such as finding the minimum of averages calculated across groups or paths. This reduces the need to move intermediate results into application code. MATCH (a:`node`)-[e:`edge`]->{1,2}(b:`node`) RETURN a.id AS id, MIN(AVG(e.weight)) AS min_average GROUP BY id COLLECT_ONE, COLLECT_LIST, and COLLECT_ELEMENTS Collection functions retain values or graph elements for evaluation as a group. COLLECT_ONE selects one value, COLLECT_LIST builds a list, and COLLECT_ELEMENTS gathers graph elements. They are useful for path-level checks, ordered output, and analysis across repeated relationships. MATCH (p:`node` {id: 1})-[e]->{2}(p1:`node` {id: 1}) RETURN (COLLECT_ONE(e.weight) IN [e[0].weight, e[1].weight]) AS contained MATCH ()-[e]->{1,2}() RETURN COLLECT_LIST(ALL e.weight) AS w ORDER BY w LIMIT 20 MATCH ()-[a:ACTED_IN]->{0,4}() WHERE SIZE(COLLECT_ELEMENTS(DISTINCT a.roles)) > 4 RETURN TO_JSON_STRING(a.roles) AS r Work with values and text Dynamic nested data Support for dynamic nested data lets queries work with richer values that do not fit a flat property model. This is useful when graph entities contain structured application payloads, nested attributes, or evolving schemas. CAST CAST converts a value to a supported target type. Explicit conversion makes comparisons and calculations more predictable when source data contains different numeric types. RETURN CAST(42 AS DOUBLE) AS double_res, CAST(42 AS UINT) AS uint_res, CAST(42.5d AS INT) AS int_res RANGE RANGE creates a numeric sequence. A generated sequence can support iteration, testing, bucketing, and list-oriented calculations within a query. RETURN RANGE(0, 4) AS res POWER POWER performs exponent calculations. It extends the numeric expressions available for scoring, weighting, and mathematical transformations. RETURN POWER(-2, 3) AS res NORMALIZE and IS NORMALIZED Unicode text can have visually identical but technically different encodings. NORMALIZE converts text to a normalization form, while IS NORMALIZED checks its current form. This supports more consistent matching and grouping across multilingual data. RETURN NORMALIZE('cafe\u0301') AS normalized_text RETURN 'cafe\u0301' IS NFKD NORMALIZED AS is_normalized Regular-expression functions The MSFT.REGEXP functions match, count, locate, extract, and replace text patterns. They help prepare identifiers, names, codes, and descriptions before those values are compared or summarized. RETURN MSFT.REGEXP_LIKE('café', 'caf.') AS x RETURN MSFT.REGEXP_COUNT('abcabcabc', 'abc') AS n RETURN MSFT.REGEXP_INSTR('hello world', 'world') AS p RETURN MSFT.REGEXP_REPLACE('a1b2c3', '[0-9]', '#') AS s RETURN MSFT.REGEXP_SUBSTR('abc123def', '[0-9]+') AS s Design guidance Use the narrowest pattern that answers the question. Start from selective nodes, specify relationship and node labels, and apply filters early. Use bounded traversal when the business question has a natural maximum. When depth is unknown, combine an unbounded path with an appropriate path mode and test it against representative graph density. Return only the properties or path elements the application requires. Feature availability can vary by environment and release stage. Confirm the release stage and regional availability of each feature before publication. If availability differs by feature, identify the applicable release stage in each section. Next steps Start with a connected-data scenario such as lineage, dependency analysis, recommendations, investigations, or knowledge discovery. Identify the relationships the question must follow, choose the path mode and traversal depth that match the scenario, and then use composition and aggregation features to shape the result. Graph in Microsoft Fabric overview GQL language guide for graph in Microsoft Fabric GQL graph patterns GQL standard conformance for graph in Microsoft Fabric Optimize GQL query performance for graph in Microsoft FabricDatabricks ADBC connector for Power BI and Microsoft Fabric (Generally Available)
This release is part of the broader ODBC-to-ADBC transition for Power Query connectors described in the Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric documentation. What’s new Existing connections in your semantic models, dataflows, and paginated reports continue to work unchanged — the migration path is currently opt-in per connection, per workspace, or per tenant. Highlights: Improved security - ADBC drivers incorporate security enhancements, such as memory safety and garbage collection. No changes to existing behavior - This transition moves away from the embedded ODBC drivers that ship with Power BI. It does not change behavior for the ODBC connector when you use a separately installed ODBC driver. Efficient large dataset support - ADBC provides a set of standard interfaces for interacting with Arrow data, which is especially efficient at fetching large datasets with minimal overhead and no serialization or copying. Supported authentication - Databricks ADBC supports OAuth (user), OAuth (M2M / Client Credentials), and Microsoft Entra ID. Connectors covered by this release Connector Previous driver New driver (GA) Databricks Simba Spark ODBC Databricks ADBC Azure Databricks Simba Spark ODBC Databricks ADBC How to try it You can test the ADBC driver now. We suggest you start soon to help ensure the eventual deprecation of ODBC and migration to ADBC runs smoothly. There are three ways to begin validating ADBC, ordered by how much control you want. 1. Opt in per connection using Implementation="2.0" The fastest way to compare ADBC and ODBC for a specific report or dataset. Add the Implementation="2.0" option to the source step in your Power Query expression: Source = Databricks.Catalogs("adb-1234567890.1.azuredatabricks.net", "/sql/1.0/warehouses/<warehouse-id>", [Implementation="2.0"]) Refresh the dataset and compare row counts, column types, and totals against your production baseline. If you want to force a side-by-side comparison against ODBC, use Implementation="1.0" . 2. Override the default for a validation workspace If you want to validate several reports together, a workspace admin can turn ADBC on for a single workspace while the rest of the tenant continues to use the legacy driver. Publish the reports you want to test into that workspace and run your normal refresh schedule. 3. Enable ADBC by default at the tenant level When you’re confident with the results, the tenant admin can enable Users can connect to data sources by using Apache Arrow database connectivity (ADBC) in the Admin portal. New connections across the tenant will use the ADBC driver by default, and Desktop and the service stay aligned on the same driver. What to expect during validation The ADBC driver is designed as a compatibility-preserving replacement for the Simba Spark ODBC driver. Validate your key reports in Desktop before enabling ADBC at the tenant level and report any regressions to [email protected]. Explore Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric for more information. What’s next The Power BI service will move from ODBC to ADBC through the first quarter of 2027. We recommend that you start validating today, so the tenant-level move is a non-event when it lands. We’d love your feedback Try the new Databricks ADBC driver. If anything looks different from what you'd expect — a refresh that fails, a total that changed, a performance regression — send the tenant ID, connector, M expression, and what you observed to [email protected]. Get started this week: Read the Databricks connector documentation. Install the latest Power BI Desktop. Pick one production report on Databricks and add Implementation="2.0" to its source step. Compare row counts, column data types, and key totals against your production baseline. Report anything unexpected to [email protected].T-SQL language enhancements in Microsoft Fabric Data Warehouse (Preview)
Microsoft Fabric Data Warehouse is expanding its T-SQL capabilities with four language enhancements in preview. GROUP BY ALL, ORDER BY ALL, the QUALIFY clause, and the FROM ... SELECT query format help SQL developers and data professionals reduce repetitive code, simplify query maintenance, and make analytical logic easier to understand. What’s new Four T-SQL language enhancements are available in preview: GROUP BY ALL — automatically groups by every non-aggregate expression in the SELECT list, reducing duplication between SELECT and GROUP BY clauses. ORDER BY ALL — sorts results by each column in the SELECT list, using the same column order, so developers do not need to repeat every sort expression. QUALIFY — filters rows after window functions are evaluated, so common ranking and top-N patterns no longer require an additional subquery or common table expression. FROM ... SELECT — provides an alternative query format that begins with the data source and defines the selected columns later, allowing developers to write complex queries in a source-first sequence. These additions reduce repetitive code and make query intent easier to understand. They are especially valuable when queries include many grouping or sorting columns, when analytical results require filtering, or when a source-first structure makes complex logic easier to follow and maintain. Together, these enhancements make queries easier to adapt as requirements change. Developers can add or remove projected columns with less rework, filter analytical results without an extra query layer, and organize complex queries in the sequence that best matches how they reason about the data. New capabilities: Write shorter queries with less repeated code. Make grouping, ordering, and analytical filtering easier to understand. Reduce maintenance when projected columns change. Express source-first query logic in a clear, natural sequence. Use familiar T-SQL capabilities directly in Microsoft Fabric Data Warehouse. Conclusion These T-SQL language enhancements make everyday query development in Microsoft Fabric Data Warehouse more concise and expressive. Whether you are summarizing data, sorting wide result sets, filtering window-function results, or organizing complex query flows, the new syntax helps you focus on analytical intent instead of repetitive code. For syntax, supported options, and examples, refer to the documentation for QUALIFY, GROUP BY ALL, ORDER BY ALL, and FROM ... SELECT. As you evaluate these preview capabilities, share your scenarios and feedback with the Microsoft Fabric community on Reddit.New analytical functions in Microsoft Fabric Data Warehouse (Preview)
Microsoft Fabric Data Warehouse and the SQL analytics endpoint now support new analytical functions in preview. SQL developers and data professionals can calculate medians, quantiles, and percentiles with concise, maintainable T-SQL queries. What’s new in preview MEDIAN — returns the middle value in a dataset. QUANTILE — returns the value at a specified point in a distribution. APPROX_MEDIAN — estimates the median for large datasets. APPROX_QUANTILE — estimates a specified quantile for large datasets. PERCENTILE_CONT and PERCETILE_DISC — The existing PERCENTILE_CONT and PERCENTILE_DISC analytical functions now also support aggregate syntax, complementing their window forms for continuous and discrete percentile analysis. With these functions, you can calculate distribution metrics without writing multi-step workarounds. For example, you can compare a transaction with the median for its customer segment, identify quantile thresholds, summarize performance, and explore distributions across large datasets. The following query shows the four new functions and the enhanced aggregate syntax for PERCENTILE_CONT and PERCENTILE_DISC in a Fabric Data Warehouse T-SQL workload. distribution metrics in Fabric Data Warehouse. You can use each function as an aggregate to return one result for a dataset or group, or as a window function to add the analytical result to each row while preserving the result set. Why it matters These capabilities simplify common distribution analysis: Write shorter, easier-to-maintain analytical queries. Analyze data directly in the warehouse. Choose exact calculations when precision is the priority, or approximate calculations when you need faster results across large datasets. Use the same analytical patterns across Fabric Data Warehouse and the SQL analytics endpoint. Conclusion The new functions make it easier to perform common distribution analysis directly in Fabric Data Warehouse and the SQL analytics endpoint. You can choose exact calculations when precision is the priority or approximate calculations when faster results at scale are more important, then use aggregate or window syntax to fit the analysis. This reduces custom query logic and keeps statistical analysis close to the data. For syntax, supported options, and examples, refer to the Aggregate functions (Transact-SQL) documentation. As you evaluate the preview, share your scenarios and feedback in the Microsoft Fabric community on Reddit.
