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.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.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.
Advanced NL2SQL and advanced DAX generation in Fabric data agents (Generally Available)
Data agents in Microsoft Fabric let users ask questions about data in plain language. As a creator, you connect an agent to supported sources—including SQL databases, lakehouses, Power BI semantic models, and eventhouses—add the business context it needs, and share it with users across Fabric, Teams, Microsoft 365 Copilot, Copilot Studio, and Microsoft Foundry. The data agent can then respond like a domain expert that understands what your tables mean, how your metrics are defined, and which source can answer a question. The usefulness of a data agent ultimately depends on a simple question: can it translate what a user asks into the right query? That is harder than it sounds. Enterprise schemas are rarely intuitive. Several tables, columns, measures, or join paths may appear to answer the same question, so a query can be technically valid but still return the wrong result. Advanced NL2SQL and advanced DAX generation help address this problem by allowing the agent to explore the schema and data, validate assumptions, and refine its approach before generating a query. Both capabilities are available today, and we'll begin rolling the core improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. In this post, we'll look at how they work, what our internal benchmarks show, the new configurations available for shaping how the agent behaves, and what to consider as you re-test and evaluate your data agents. Why conversational analytics gets harder with enterprise data Turning a plain-language question into a correct query is a complicated problem, both for SQL and DAX, requiring the agent to resolve several challenges at once: Schemas are large. Enterprise sources can contain hundreds of tables, columns, and measures, and the names alone may not explain when or how they should be used. Business context exists outside the data. Definitions such as “revenue” or “active customer” often live in documentation, previous queries, or analysts’ knowledge rather than in the source schema. Filter values must match the way data is stored. Users describe concepts naturally, but those concepts must map to the values in the data. For example, a user may ask about “California” when the relevant column stores the value “CA.” Questions are ambiguous. More than one column, calculation, or join may appear to satisfy a request. Individually, each of these can be managed with enough hand-written guidance. The difficulty is that they compound: a single-pass generator has to resolve all of them at once — your schema, your definitions, your filter values — committing to an interpretation before it has any evidence that interpretation is right. When it guesses wrong, the query still runs, and the answer looks no different from a correct one. Advanced NL2SQL and advanced DAX generation are built around that problem. Rather than generating a single pass, the agent gathers evidence first. Advanced NL2SQL: the agent explores before it writes The shift is architectural. Instead of one-shot generation, the agent has sub-tools to explore schema, test joins, and look up real filter values before it writes SQL. Under the hood, you can inspect each step the agent took, and the assumptions and reasoning behind it. It operates in three modes, each backed by its own sub-tools: Mode What it does Example query following Finds a relevant example query and answers by making approved modifications, such as literal filter or parameter substitutions. Clarifying questions Determines it can’t answer reliably without more information and asks targeted clarifying questions before generating SQL. Data exploration When no example directly applies, learns from existing example queries to infer business logic, explores the data to validate assumptions, and iteratively refines its approach. What you get as a creator: Advanced NL2SQL explores the SQL source schema, tests joins, and looks up real filter values before generating SQL, helping it choose the appropriate tables, columns, relationships, and filters. Schema descriptions and topics that teach the agent what your data means, so you get better answers with fewer instructions. Better example-following and filter-value substitution for novel questions. Handles large schemas far better and runs faster end to end, with more reasoning detail for debugging. New configurations: schema descriptions and topics Two new configurations give the agent more of the context it needs. Both are available for SQL data sources on the preview runtime. Schema descriptions Schema descriptions attach business context to the objects in your data source — what a table holds, what a column represents, and how each should be used. The agent uses them to interpret large or ambiguous schemas and generate a more accurate query. They matter most where object names don’t carry meaning on their own, or where several tables and columns look interchangeable. Figure: Schema descriptions add business context to schema objects, helping the data agent interpret your data. Topics Topics help you give the agent detailed guidance without sending every instruction with every question. The agent searches your topic content and uses only the sections relevant to the current request. Use data source instructions for rules that must always apply, and use topics for deeper guidance that applies only to a specific subject. You can write topics in Markdown, import multiple files, and review the run steps to see which topics the agent selected. Figure: Topics organize subject-specific instructions in Markdown to guide the data agent’s query generation. Internal benchmark testing: Advanced NL2SQL on Preview Runtime vs NL2SQL on Standard Runtime Better reasoning matters only if it produces better answers without making users wait substantially longer. In an internal benchmark set evaluating answer quality and end-to-end latency, the preview runtime delivered the stronger outcome, answering more questions correctly than the standard runtime while reducing both median and tail latency. Smart-answer accuracy increased from 78.8% to 90.9%. Latency improved at the same time: P50: 28.4 seconds to 26.0 seconds P95: 46.8 seconds to 32.9 seconds Figure: Smart answer accuracy and end-to-end latency, standard runtime versus the Advanced NL2SQL preview, on an internal benchmark set. Accuracy rises 12.1 points to 90.9%, while P50 latency falls 8.3% and P95 falls 29.8%. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal evaluation set comparing standard NL2SQL to the advanced NL2SQL preview in Microsoft Fabric. Actual results may vary depending on workload, data model, and configuration. The P95 result shows the largest latency improvement in this benchmark, with latency decreasing from 46.8 seconds to 32.9 seconds. This improvement is most relevant to the slower, more complex queries represented at the tail of the distribution. Advanced DAX generation: agentic reasoning over semantic models The agent calls tools, inspects results, and refines its approach to answer harder questions. Instance value indexing searches real column values, so filters match your data. And you get consistent results across Data Agent, Power BI, and M365 Copilot. For users, this means the agent is more likely to resolve filter terms to the values stored in the semantic model and return consistent answers across supported Microsoft experiences. Internal benchmark testing: Advanced DAX generation improves accuracy while cutting latency Our internal Advanced NL2DAX evaluation showed improvements in both answer accuracy and latency. Smart-answer accuracy increased from 89.15% to 91.86%. At the same time: P50 latency: 39.1 seconds to 20.4 seconds P95 latency: 97.5 seconds to 34.7 seconds This represents an approximately 48% reduction in P50 latency and a 64% reduction in P95 latency, along with a 2.7 percentage-point increase in smart-answer accuracy. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal DAX generation evaluation set comparing the baseline to the advanced DAX generation preview in Microsoft Fabric. Actual results may vary depending on workload, semantic model, and configuration. Rolling out the runtime improvements We'll begin rolling the core Advanced NL2SQL and advanced DAX generation improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. As part of this rollout, the standard runtime will also move to GPT-5.6 Terra. As the rollout reaches your environment, data agents using the standard runtime will receive these improvements and the model upgrade by default, with no opt-in required. What is moving to the standard runtime: Advanced NL2SQL: improved example-query following, filter-value substitution, and data exploration. Advanced DAX generation: the agentic tool-calling loop and instance value indexing. Model upgrade: The standard runtime will move to GPT-5.6 Terra for orchestration and supported data agent capabilities. What stays in preview: Schema descriptions and topics for SQL sources. We believe these changes deliver significantly better results, based on improvements observed in our internal evaluations. However, results can vary by data source, model, instructions, examples, and workload. Creators can re-test and evaluate their agents on the standard runtime between November 2 and November 10 as the rollout reaches their environment, or try the changes now on the preview runtime. Moving from one-shot generation to an agent that explores data can change how existing instructions and examples are interpreted. We recommend re-testing: Run your existing question set against the standard runtime as the rollout reaches your environment between November 2 and November 10, or switch to the preview runtime to try the changes now. Rerun your evaluations with the Fabric data agent SDK and a ground-truth set. Compare the new results with your previous baseline, and use the visible reasoning steps to identify where the agent’s assumptions differ. Tune your example queries and instructions based on what the evaluation shows. The agent now explores your data and adapts examples through substitution, so guidance written to work around the previous behavior may no longer be needed. Re-testing and evaluating your agents will help you confirm the expected quality improvements for your own data and scenarios. Next steps If you build data agents in Microsoft Fabric, re-test your agents on the standard runtime as the rollout reaches your environment between November 2 and November 10, or try the changes now on the preview runtime. For more details: Fabric data agent runtime: Learn what the standard and preview runtimes each contain, how to switch between them, and what’s in the preview runtime today. SQL sources in Fabric data agent: Learn how NL2SQL and Advanced NL2SQL generate queries over Lakehouse, Data Warehouse, SQL Database and Mirrored Database sources, and which configurations each one can use. Semantic model best practices for data agent: Semantic model best practices for data agent: Learn about advanced DAX generation and how to prepare a semantic model so the agent can answer questions accurately.
Custom SQL Pools in Fabric Data Warehouse (Generally Available)
Custom SQL Pools in Microsoft Fabric Data Warehouse are now generally available, along with statement type classification. Custom SQL Pools give administrators more control over how compute resources are allocated across different workloads in a Fabric workspace. You can isolate workloads into separate pools, set maximum resource allocation percentages, and help ensure that one workload doesn’t consume resources intended for another. For example, you can create separate pools for data ingestion, reporting, and ad hoc analysis, then configure the maximum percentage of compute resources each pool can consume. Custom SQL Pools complement the autonomous workload-management capabilities built into Fabric Data Warehouse while giving organizations additional control for predictable and business-critical workloads. Classify workloads by statement type Statement type classification provides a simple way to separate read and write workloads. When configuring Custom SQL Pools, you can classify distributed SQL requests into two categories: SELECT for read queries. NONSELECT for statements such as data loading and modification operations. Fabric creates separate pools for the two statement categories, with an initial maximum allocation of 50% for each pool. Administrators can adjust these percentages based on workload requirements, provided their combined maximum allocation doesn’t exceed 100%. Statement type classification is useful when organizations want to protect interactive reporting capacity from intensive ingestion or data-transformation workloads without relying on application names or connection properties. Custom SQL Pools also support application-based classification using an exact application name or a regular expression. Administrators can select the classification model that best reflects how workloads connect to and use their Fabric workspace. Get started To learn about Custom SQL Pools, supported classifiers, resource allocation, and workload behavior, review the Custom SQL Pools documentation. For instructions to create and configure pools in the Fabric portal, review the Configure Custom SQL Pools in the Fabric Portal documentation.OneLake Security on the SQL Analytics Endpoint
OneLake Security centralizes fine-grained data access for Microsoft Fabric data items and enforces it consistently across engines. Currently in Preview and opt-in per item, it lets you define roles over tables or folders and optionally add Row-Level Security (RLS) and Column-Level Security (CLS) policies. These definitions govern what users can see across Fabric experiences. When you first opt in, a DefaultReader role preserves prior read access. You can remove or adjust this role to transition toward a least-privilege model. OneLake Security in the Context of SQL Analytics At its core, OneLake Security is an item-scoped RBAC and policy layer. You can: Create data-access roles Attach tables or folders Add policies (RLS, CLS, object-level permissions) Membership can be: Explicit – users or groups within the workspace (for example, those assigned the Viewer role) Inherited – via shared items such as a Lakehouse or shortcut Once published, these rules apply to data access from all engines, including the SQL Analytics Endpoint. (See Microsoft Learn.) Understanding OneLake Security for SQL Endpoint The SQL Analytics Endpoint is a read-only surface over Lakehouse data. When OneLake Security is enabled on a Lakehouse, the endpoint enforces those same Lakehouse policies in one of two access modes. Write operations continue to be governed by workspace roles within the Lakehouse experience.” (See Microsoft Learn.) Since there are two access modes, let’s look at how each determines security enforcement: User identity mode (central governance in OneLake) The signed-in user’s identity is passed through to OneLake; table reads are governed entirely by OneLake roles and policies (SQL GRANT/REVOKE on tables is ignored). You still can use SQL permissions for non-table objects (views, procs, functions). This gives 'define once, enforce everywhere' behavior across Power BI, notebooks, Lakehouse, and SQL. Delegated identity mode (SQL-centric control at the endpoint) The endpoint reads OneLake using the item/workspace owner identity; SQL enforces access (roles, GRANT/REVOKE, SQL-defined RLS/CLS, DDM) for the querying user. Use this when you need classic DBA patterns or utilize SQL specific security functions. Ensure the owner has read access in OneLake; otherwise, queries will fail. Differences Between the Modes Tables: User identity: controlled by OneLake roles; SQL GRANT/REVOKE is not allowed on tables. Delegated identity: controlled by SQL; full GRANT/REVOKE. Views / Stored Procedures / Functions: Both modes allow SQL permissions (e.g., GRANT SELECT on views, GRANT EXECUTE on procs/functions). RLS/CLS/DDM: User identity: RLS/CLS are defined in OneLake role UI; DDM isn’t part of OneLake Security. Delegated identity: RLS/CLS/DDM are defined in SQL (security policies, column grants, masked columns). Workspace roles: In User identity, Admin/Member/Contributor bypass OneLake policies; Viewer or read-only sharing is required for enforcement. Shortcuts: Remote Data Ownership and Practical Considerations Shortcuts surface data from another Lakehouse (or external source) into your item. The security policy is enforced at the source; when SQL queries shortcut tables, the system honors the originating OneLake roles/RLS/CLS. Security sync also validates shortcuts, so remote policies aren’t bypassed. Design tips: Document role mappings across items (consumer ↔ source) so troubleshooting is straightforward. Expect validation when shortcut targets change (rename/move); allow brief propagation time. Configuration: Enabling and Setting OneLake Security for SQL Endpoint Opt-in to OneLake Security on the Lakehouse (Manage OneLake security). Review the DefaultReader behavior; remove it or adjust to move to least-privilege. Create roles → select tables/folders → add explicit/virtual members → optionally set RLS/CLS. In the SQL Analytics Endpoint → Security, choose OneLake access mode: User identity (enforces OneLake roles only). Delegated identity (enforces SQL permissions + OneLake security for the owner) Confirm the change in the pop-up. Important switching behavior: Switching to User identity ignores SQL table permissions and can delete existing SQL roles on tables; switching to Delegated stops applying OneLake roles/policies to table reads for all users except the owner. Plan cutovers and back-ups accordingly. How It Works Under the Hood: Security Sync and (Meta)Data Validation When the endpoint runs in User identity mode, a background security sync service keeps SQL aligned with OneLake: it detects role changes, user assignments, and table/policy updates; it translates OneLake RLS/CLS into SQL-compatible constructs and validates that shortcut targets remain consistent, so the source’s policies are honored. Expect non-instant propagation (measure in minutes, not hours) and explicit errors if policies reference dropped/renamed columns—fix in OneLake and re-publish. In Delegated identity mode, SQL is authoritative for the end user access. The endpoint authenticates to OneLake as owner, and the SQL permission model (roles, grants, RLS/CLS/DDM) determines access. Any mismatch between owner access to the Lakehouse and SQL grants will surface as query failures until corrected. Bringing It All Together OneLake Security brings a single, authoritative policy surface to Fabric and lets you decide how the SQL Analytics Endpoint enforces it: Choose User identity when you want to define once in OneLake, enforce everywhere (and ensure workspace users are Viewer/read-only so policies apply). Choose Delegated identity when you need classic SQL control (roles, grants, RLS/CLS/DDM) or to align with existing DBA tooling. By unifying governance across SQL and Lakehouse, Fabric helps teams move faster while staying secure. We’re actively working on additional features, so stay tuned for more updates! Resources To learn more, refer to the OneLake Security for SQL analytics endpoints (Preview), OneLake security overview documentation, and The next evolution of OneLake security (Preview) blog post.Building the Bronze → Silver → Gold layers
Part two of a series on medallion architecture with Fabric Data Warehouse One job per layer — with enough implementation detail to make it real In Part 1 of this series, you picked your pattern. Now, let’s fill in the layers. The single most useful mental model here: each layer has exactly one job. Most medallion messes come from a layer doing another’s work — cleaning data in Bronze or letting business logic creep into Gold. In this post, we’ll look at hose Bronze, Silver, and Gold layers are implemented in Fabric Data Warehouse (DW), the T-SQL patterns commonly used in each layer, and the practices that help keep your architecture maintainable as it grows. We’ll also cover which practices are worth calling out before we move deeper into best practices in Part 3 of this series. Here’s what “one job” means in Fabric DW. Bronze — land it, don’t touch it Bronze has one job: ingest all source data in its original raw form, with no business logic or cleansing applied — “write everything down first” — so you preserve a source-of-truth copy you can always refer back to. In Fabric DW, that usually means staging tables that closely mirror the source structure, placed in a dedicated Bronze schema, such as Bronze.SalesOrdersRaw, to clearly mark them as raw. If the source is a relational extract, the Bronze table often follows the source columns. If the source is semi-structured, keep parsing to the minimum needed to land and trace the data. For loading, Fabric DW supports Data Factory Pipelines, Dataflows, COPY INTO, T-SQL ingestion, OPENROWSET, and Spark-based patterns. A common and efficient path is the T-SQL COPY INTO command to bulk-load files from OneLake or external storage into a DW table. Implementation sketch: CREATE SCHEMA Bronze; CREATE TABLE Bronze.CustomerRaw (CustomerID INT NULL, Name VARCHAR(100) NULL, Email VARCHAR(100) NULL, CreatedDate DATETIME2 NULL, RawFileName VARCHAR(255) NULL ); COPY INTO Bronze.CustomerRaw FROM 'https://<storage>/exports/customers/*.csv' WITH (FILE_TYPE = 'CSV', FIRSTROW = 2, FIELDTERMINATOR = ','); Hybrid note: if the raw data needs Spark-heavy preparation, land it in a Lakehouse for Bronze and then either expose it to the warehouse or begin Silver in Fabric DW. The rule does not change: Bronze is still raw, traceable, and rebuildable. Do this well: Preserve raw data. Do not filter out “bad” records in Bronze; all cleaning happens in Silver. Use batch loads, not row-by-row inserts. Small trickle inserts create many small Delta files and hurt performance. Keep file and schema discipline. Match the source structure and handle schema evolution by adding nullable columns rather than dropping source information. Add metadata columns like ingestion timestamp or source filename for traceability and auditing. Automate recurring loads with Fabric Pipelines or scheduled SQL scripts, so Bronze remains repeatable. Silver — Clean it once, for everyone Silver’s one job is to take raw Bronze data and apply cleaning, validation, and integration. This is where you remove duplicates, standardize formats, handle missing or invalid values, join related sources, and apply shared business rules. In Fabric DW, Silver is typically implemented with T-SQL transformations from Bronze into curated Silver tables. Use CTAS, or CREATE TABLE AS SELECT, when you want to materialize a clean table from a query. Use INSERT...SELECT or MERGE when the pattern is incremental. The important design point: Silver should become the single source of truth for cleansed data in the pipeline. You might keep one Silver table per Bronze source or combine multiple Bronze inputs into one conformed Silver table, such as a consolidated customer table. Implementation sketch: CREATE SCHEMA Silver; CREATE TABLE Silver.CustomerCleaned AS SELECT CustomerID, Name, IIF(Email NOT LIKE '%@%.%', NULL, Email) AS Email_Valid, CONVERT(DATETIME2(6), CreatedDate) AS CreatedDate FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY CustomerID ORDER BY CreatedDate DESC) AS rn FROM Bronze.CustomerRaw ) AS t WHERE rn = 1; Hybrid note: if Bronze lives in a Lakehouse, Silver can be handled with Spark, Dataflows, or T-SQL after the data is exposed to the warehouse. Use Dataflows for lighter citizen-developer transformations; use Spark or T-SQL when scale, repeatability, or engineering complexity matters. Do this well: Make transformations idempotent, so they can run repeatedly without damaging data. Validate and enforce quality here. Silver is the gate where bad data gets stopped, fixed, or flagged. Use MERGE for incremental upserts when late-arriving data needs to update Silver instead of forcing a full reload. Use staging or temporary tables when the logic gets complex; simpler modular SQL is easier to maintain. Keep performance visible. Complex joins and aggregations belong here, but they should be written in a way the warehouse can optimize and the team can reason about. Gold — Shape it for the question Gold’s one job: present business-ready data that Power BI, dashboards, and downstream analytics can use directly. This is usually where you shape the model into facts and dimensions, data marts, wide reporting tables, or pre-aggregated summaries. In Fabric DW, this is where the warehouse shines. Gold tables are built with SQL transformations from Silver, often involving joins, calculated fields, and aggregations. The payoff is that report authors and business users do not need to repeat heavy transformations in every semantic model or dashboard. To create Gold tables, start from clean Silver data and optimize for the business question. For example, transaction-level Silver data can become a daily sales summary table used directly by Power BI. Implementation sketch: CREATE SCHEMA Gold; CREATE OR ALTER VIEW Gold.v_Customer AS SELECT CustomerID, Name, Email_Valid AS Email, CreatedDate FROM Silver.CustomerCleaned; CREATE TABLE Gold.DailySalesSummary AS SELECT CAST(s.OrderDate AS date) AS OrderDate, COUNT(DISTINCT s.OrderID) AS TotalOrders, SUM(s.TotalAmount) AS TotalSalesAmount, COUNT(DISTINCT s.CustomerID) AS UniqueCustomers FROM Silver.SalesCleaned AS s GROUP BY CAST(s.OrderDate AS date); Consumption: once Gold tables or views are created in Fabric DW, they are directly queryable by BI tools. Because the data is clean, aggregated, and shaped for use, consumers can treat Gold as the trusted version of the truth for analytics. Do this well: Model for analytics. If using a star schema, define the right grain for facts and use clean dimension tables. Use aggregations to reduce data volume and make common queries fast. By Gold, sensitive data should be removed, masked, or protected with row-level or column-level security. Document lineage, especially how Gold fields are derived from Silver. Decide a refresh strategy. Gold is usually rebuilt or incrementally updated on a schedule. Encapsulate repeatable refresh logic in stored procedures when that makes the pipeline easier to operate. The layers at a glance Use this as a quick health check for your Fabric DW medallion design. Layer Its one job In Fabric DW Watch out for Bronze Preserve raw source data Staging tables, COPY INTO, metadata columns Cleaning too early; tiny files Silver Clean, validate, and conform CTAS, INSERT...SELECT, MERGE, quality gates Non-repeatable transformations Gold Serve trusted analytics Facts, dimensions, marts, aggregations Business logic leaking in late Takeaway Data flows Bronze (raw) → Silver (cleaned) → Gold (curated) — and the discipline is in the arrows. If you can point at any table and say which single job it serves, your medallion architecture is healthy. When something breaks in Gold, a clean Bronze layer and a repeatable Silver layer let you recompute from scratch instead of reverse-engineering business logic from reports. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline In the next post, we'll explore the Fabric DW-specific best practices that keep all three layers fast, reliable, and governable.
Modernize your Azure Data Estate with Microsoft Fabric: A guided path from Azure Data Factory and Azure Synapse
Authors: Faisal Mohamood and Bogdan Crivat 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. Most enterprise analytics estates were assembled rather than designed. A tool for ingestion, another for transformation, a warehouse for data processing, a lake for everything else, and a layer of glue holding it together. That architecture did its job for a decade, but it was built for a world where data moved on a schedule and insight could wait. AI changed the deadline. The organizations pulling ahead today are the ones consolidating on a single platform where data, analytics, and AI share one foundation instead of one integration backlog. For teams running Azure Synapse Analytics and Azure Data Factory, Microsoft Fabric is the next step in that investment—not a departure from it. Fabric unifies data integration, engineering, and warehousing in one SaaS experience, reducing the operational burden of disparate tools and creating a clearer path to AI-driven workloads. The question customers now ask are not whether to modernize, but how to do so without disrupting the pipelines their businesses rely on every day. Upgrade to Fabric Data Factory with confidence Azure Data Factory has earned the trust of customers worldwide by powering mission-critical data integration workloads. Organizations that rely on Azure Data Factory and Azure Synapse pipelines have built critical data integration foundations that form the backbone of their business operations. Fabric Data Factory builds on that trusted foundation while bringing customers into a unified data platform for AI transformation. With OneLake, Copilot-powered experiences, integrated analytics, and Fabric-native innovation, customers can modernize their data integration estate while preserving the investments that matter most. At FabCon Barcelona, we are excited to announce a streamlined upgrade experience that helps Azure Data Factory customers begin their journey to Fabric Data Factory with confidence. This new experience enables Azure Data Factory customers to bring their existing data factory into Microsoft Fabric, view their Azure Data Factory pipelines directly within Fabric, and continue using familiar management and monitoring experiences, all before making any migration decisions. Customers can experience Fabric immediately while preserving their existing Azure Data Factory investments. This is another important step toward our vision that every Azure Data Factory customer can become a Fabric Data Factory customer. The experience is built around three principles we consistently heard from customers: transparency, control, and confidence. Customers want to understand what will change, what will remain the same, and when they should modernize. We provide a guided path that allows organizations to explore, assess, validate, and upgrade on their own terms. The journey begins directly from Azure Data Factory with a simple view in Fabric experience. Customers can bring their Azure Data Factory environment into a Fabric workspace and immediately see their familiar data factory assets and pipelines within the Fabric experience. Existing Azure Data Factory assets remain the source of truth, while customers gain access to Fabric as a natural extension of their current experience. This allows teams to become familiar with Fabric, explore the broader Fabric platform, and understand the value of a unified data estate without disrupting production workloads. Once inside Fabric, customers can evaluate their readiness for Fabric Data Factory using built-in migration assessment capabilities. The assessment provides visibility into pipeline and activity compatibility, helping customers understand which workloads are ready to upgrade, which may require review, and which capabilities are planned for future support. By surfacing compatibility information upfront, customers can make informed modernization decisions and prioritize migration efforts based on business needs. Connection mapping and migration guidance further simplify planning and reduce manual effort. This assessment-first approach is a direct response to customer feedback. Trust is built through visibility, and customers consistently told us they want a clear understanding of readiness before committing to change. After reviewing assessment results, organizations can choose when and how they upgrade to Fabric Data Factory. Supported pipelines can be upgraded incrementally, allowing teams to validate outcomes, gain operational confidence, and modernize at the pace that makes sense for their business. Existing Azure Data Factory workloads can continue operating while organizations evaluate and transition workloads over time. This staged approach helps reduce risk while enabling customers to realize the benefits of Fabric Data Factory and the broader Microsoft Fabric platform. The upgrade journey from ADF to FDF allows customers to plan, explore Fabric, assess readiness, validate outcomes, and upgrade when ready. The journey from Azure Data Factory to Fabric Data Factory is designed to be transparent, low-risk, and customer-driven, helping every Azure Data Factory customer become a Fabric Data Factory customer on their own terms. Read more about the Fabric Data Factory announcements at FabCon Barcelona. Guided migration with Microsoft-approved partners Microsoft-approved partners can guide customers’ upgrade from start to finish, or customers can explore the upgrade independently with no effect on their existing Azure Data Factory pipelines. Customers can now request partner-guided upgrade support online and get connected with Microsoft partner expertise to help plan and execute their Fabric Data Factory upgrade. Partners can help assess the customer’s environment, prioritize workloads, address compatibility requirements, develop the upgrade plan, execute and validate upgrades, and accelerate deployment to production. Learn more about how partners can help guide migration. Modernizing Spark workloads with Fabric Data Engineering Fabric Data Engineering provides a unified foundation for building and scaling Apache Spark workloads alongside the rest of the analytics estate. With capabilities such as the Native Execution Engine, high concurrency, and starter pools, teams can improve performance, reduce operational overhead, and work more easily with shared data in OneLake. The Spark in Azure Synapse to Fabric Data Engineering migration assistant accelerates modernization by migrating Spark pools, notebooks, and Spark job definitions, while mapping lake databases through OneLake catalog shortcuts. Artifacts are copied while data remains in place, allowing existing pipelines to continue running without downtime. A guided experience tracks progress and provides a detailed report of what migrated successfully and what requires attention. OBOS, one of the Nordic region’s leading residential developers, used a phased approach to migrate more than 600 notebooks and pipelines and consolidate over 4,500 data objects into 87 lakehouses. By validating technical results and live business KPIs across both environments before cutover, OBOS reduced operational costs by 20% and accelerated data processing by 30%. “We deliberately ran the old and new environments in parallel, comparing row and column counts and validating business KPIs through live reports before we switched anything over. That rigorous validation mattered, because for a data platform like ours, trust is the product.” - Dag Erlend Berger, Product Lead for the Data Platform, OBOS Complementing the migration assistant, the Fabric data engineering agent (Project Osmos), now in preview, helps accelerate the engineering work that goes beyond moving artifacts. Teams can delegate complex migration and modernization tasks, such as adapting Spark notebooks, refactoring pipelines, and validating migrated workloads. Osmos inspects the relevant data and code, plans and executes the work in Fabric, and iteratively validates and refines the results against the task’s requirements. Authorized teammates can contribute context and steer the same persistent task, with Fabric permissions governing access. This helps reduce manual engineering effort while keeping quality, maintainability, and team oversight central to the transition. Accelerating query performance with Fabric Data Warehouse For organizations managing data volumes in terabytes or petabytes, Fabric Data Warehouse provides superior performance and cost efficiency compared to Synapse dedicated SQL pools. The migration assistant for data warehouse simplifies and automates this transition for existing Synapse customers. The assistant, built directly into the Fabric experience, provides a guided path to convert artifacts from Synapse dedicated SQL pools into Fabric Data Warehouse, helping with schema conversion and data movement alike. It delivers a clear, actionable snapshot of migration results alongside a detailed summary of items that need attention, and Copilot is available to help resolve issues on the spot. To further reduce migration effort, the migration assistant gives customers the flexibility to migrate only what they need. Customers can select specific schemas or individual objects instead of migrating an entire environment, with visibility into object dependencies and guidance on related artifacts that should be migrated together. This allows organizations to break large modernization projects into manageable phases while maintaining confidence that dependent objects are accounted for. Large-scale modernization programs are inherently iterative. Source systems continue to evolve while migration projects are underway, creating a challenge for organizations that need to keep target environments synchronized without repeatedly restarting migration efforts. To address this, we introduced incremental migration support in Migration Assistant. Customers can return to an existing migrated warehouse at any time and apply new changes from their source system, whether they are using a live connection or uploaded SQL files. The experience intelligently identifies differences, helps resolve conflicts, and updates only what has changed, transforming migration from a disruptive, start-over exercise into a repeatable, low-friction process. This significantly reduces the operational burden on migration teams and makes it easier for organizations to move to Fabric with greater confidence. Dentsu, a global advertising and public relations company, was dealing with data growing faster than what its teams could keep up. In partnership with OneLake GmbH, Dentsu accelerated its migration to Fabric, applying deep technical expertise to design a scalable, enterprise-grade analytics platform. “Fabric has evolved beyond self-service analytics to a full enterprise-class platform. By combining data warehousing, lake storage, and Power BI, we’ve unlocked a foundation that sparks curiosity and innovation. People naturally ask, ‘What can I build on top of this?” —Patrick Sura, Global Reporting Architect, Dentsu Nebraska Furniture Mart, a Berkshire Hathaway company managing a large BI estate under significant performance and resource pressure, migrated to Fabric Data Warehouse using the migration assistant. “The tool facilitated every step of the process, automatically addressed column type conflicts, and effectively handled data migration right after the metadata transfer.” — Siri Kakumanu, Senior Manager, Data Analytics and Business Intelligence, Nebraska Furniture Mart Read more about Analytics announcements at FabCon Barcelona. The future of your data estate starts now Whether you are modernizing data pipelines, scaling analytics workloads, or simplifying Spark operations, these tools are designed to help you move forward with confidence and at your own pace. If you want to learn about the migration paths available to Fabric, start with Azure to Fabric Migration site. If you’ve scoped your migration, use cases and are ready to get started, check out our migration documentation for guidance and actionable steps. If you’re looking for hands-on support, connect with your Microsoft account team or visit the Microsoft Fabric Community to learn from customers who have already made the move.
We Put a GPU Behind Fabric DW
At Microsoft Build, Fabric Data Warehouse announced GPU-accelerated query execution. I’ve been running it against TPC-H, and the numbers are worth sharing, along with the methodology, because I’d rather hand you enough detail to check my work, and let you it yourself. This has been one of the most complex and deeply technical projects I’ve been involved in at Microsoft, reminding me of the days of developing Vertipaq more than 16 years ago. And it’s also been one of the most rewarding projects. A few disclaimers up front: This is not an official performance test. This is me playing with freshly released tech and building an app over a weekend. I’ve almost certainly missed a few best practices — but then, so will most customers when they first turn this on. So, take these as “what a curious person gets out of the box,” not “what the engineering team can extract with perfect tuning.” That’s arguably the most honest number anyway. Also, this feature is now in limited availability, primarily due to GPU availability, and not yet in all Azure regions. I really wanted to test it as a customer would, on a commercial installation (instead of an internal test lab), and finding the right region took a bit of effort. Test environment setup (so you can trust the numbers) First, it’s worth mentioning that this test — this technology — runs entirely on data in OneLake. All in parquet, no tricks or duplicate copies. Capacity: Fabric F64 Trial Dataset: TPC-H at 100 GB scale factor Topology: Client test machine and Fabric capacity in the same Azure region (no cross-region latency padding the results). Result set caching: Deliberately disabled. Cached result sets make any engine look brilliant. I wanted to measure actual query execution, not cache hits. Workload: The full TPC-H query set, 22 queries Turning it on: A single workspace toggle that starts in your Workspace settings → Data Warehouse → Query acceleration (Preview). One switch, no infrastructure to provision. Results for single users: Every query under 500ms On a single connection, each of complete in under half a second on GPU. The slowest (Q21, Suppliers Who Kept Orders Waiting) averages 445ms. The fastest (Q6) was 140ms. The order of execution for the queries is randomized, and while the query patterns follow TPC-H, the various scalar values used in query predicates are also randomized (to simulate a real dashboard pattern). The CPU baseline for the same single-user run sits around 1.6s at the median — ry (or 4x at the mean), before any concurrency comes into play. In fact, excluding the one off at 458.5 ms, they all stay below 320 ms. queryId queryName errors avgLatencyMs p95LatencyMs Q1 Pricing Summary Report 0 248.5 255.1 Q2 Minimum Cost Supplier 0 173.8 180.2 Q3 Shipping Priority 0 217.2 221.7 Q4 Order Priority Checking 0 190.1 196.8 Q5 Local Supplier Volume 0 254.1 259 Q6 Forecasting Revenue Change 0 140.3 144.2 Q7 Volume Shipping 0 252.6 257.6 Q8 National Market Share 0 273.3 282.5 Q9 Product Type Profit Measure 0 315.8 320.2 Q10 Returned Item Reporting 0 247.8 251 Q11 Important Stock Identification 0 279.3 287.3 Q12 Shipping Modes and Order Priority 0 196.7 203.8 Q13 Customer Distribution 0 184.2 188 Q14 Promotion Effect 0 153.6 157.4 Q15 Top Supplier 0 171.5 176.1 Q16 Parts/Supplier Relationship 0 155.9 162.2 Q17 Small-Quantity-Order Revenue 0 230.9 240.1 Q18 Large Volume Customer 0 306.9 315 Q19 Discounted Revenue 0 197.2 202.9 Q20 Potential Part Promotion 0 251 257.1 Q21 Suppliers Who Kept Orders Waiting 0 444.8 458.5 Q22 Global Sales Opportunity 0 171.3 175.9 It is worth noting that a sequential, standard TPCH suite execution (same tool, I just remove randomization of queries) is about 5.02 seconds in my experiment, which is impressive in itself! Results for high concurrency Single-user benchmarks are vanity. Real warehouses serve many analysts, dashboards, agents, and apps hammering the same capacity at once. This is where the GPU and CPU query execution engines stop resembling each other. Throughput (queries/sec) as concurrency climbs: Concurrent U CPU q/s GPU q/s 1 0.65 4.56 64 3.70 111.4 128 7.19 104.8 256 5.44 60.3 512 10.89 115.9 1000 16.93 101.4 CPU throughput tops out around 17 q/s. GPU sustains roughly 100+ q/s across the range. (Note of honesty: the 256-user GPU row is a noisy sample — clearly under its neighbors. I’m re-running it, but I’d rather show you the raw number than quietly delete the inconvenient one.) This is something I need to test with a larger capacity, perhaps F128 or F256. At 1000 concurrent users: CPU GPU Throughput 16.9 q/s 101.4 q/s p50 latency 42.8 s 8.1 s p95 latency 97.7 s 15.1 s Read the latency row carefully. Under heavy load, CPU p95 approaches 100 seconds — the kind of number where users assume the dashboard is broken and file a ticket. GPU holds p95 at 15 seconds with 6x the throughput. Fewer resources per query, more queries served, lower tail latency. That’s not just faster. At high concurrency, the overall workload can be cheaper because you're doing more work with the same capacity and getting more done for the same cost. So, is the GPU-acceleration really worth it? The honest way to value isn't 'X times faster'; it's how much CPU capacity would I have to buy to match it? At 1000 concurrent users on the same F64, GPU delivers 101 q/s versus CPU’s 17 q/s — almost exactly 6x the throughput from the same capacity, flipped on with one toggle. Put differently: to match GPU throughput on CPU, you’d need roughly 6x the capacity — an F64 would have to grow to something like an F384. And that’s the generous reading, because it assumes CPU throughput scales linearly with capacity, which it doesn’t (look at the CPU column above — going from 64 to 1000 users barely moves it from 3.7 to 17 q/s). In practice, you’d likely need even more. So, the value of the feature shows primarily at high concurrency, exactly what we expect from agents and dashboards operating directly over the lake. The flip side, stated just as plainly: at a single user, GPU does 4.56 q/s vs CPU’s 0.65 — better, but a difference you may not even feel on one interactive query. The GPU-acceleration earns its money under load, not at the desk of one analyst running one query. If your warehouse is lightly used, plain CPU execution is the right, cheaper choice. If fifty dashboards hit it at 9am Monday, the math changes completely. That’s the whole value story in one line: marginal at idle, decisive at concurrency. The test harness: Built on Rayfin The load-testing app (which, I’ll admit, looks better than most internal tools have any right to, and far better than anything I could’ve built manually) was built with Rayfin — Microsoft’s new open-source SDK and CLI for building Fabric apps, announced at Build 2026. You define the backend in code, run Rayfin up, and it deploys a fully managed, governed backend on Fabric with data landing in OneLake by default. There’s a pleasing symmetry to it: I built the tool that stress-tests Fabric DW on Fabric, using the new app platform. Dogfooding all the way down. The tech, partnership and hardware powering this The research behind these numbers is published in the CoddSpeed: Hardware Accelerated Processing in Microsoft Fabric paper, which won the Best Industry Paper award at SIGMOD 2026 — peer-reviewed by the database research community. Full disclosure: I’m a co-author. I mention that not to take credit, but because you should know my bias when I tell you the research is solid. NVIDIA accelerated computing is critical to these dramatic speedups. Custom CUDA kernels integrate NVIDIA accelerated computing directly into the Fabric Data Warehouse execution engine, enabling highly parallel processing. partnership with NVIDIA has been crucial for this release, and our teams worked hard together with our NVIDIA partners to get this product to market. Ian Buck, Vice President of Hyperscale and HPC at NVIDIA shares with us his perspective: “AI applications are redefining how a data warehouse needs to perform. As AI agents reason over enterprise data, analytics systems need low-latency performance for many simultaneous users. With NVIDIA accelerated computing and custom CUDA kernels built directly into Microsoft Fabric Data Warehouse, Microsoft is bringing the SQL workflows customers already use into the production AI era.” The honest caveats I picked 100 GB because, while not very large by big data standards, it is a reasonable range for an enterprise dashboard. Also, it is a reasonable size for a weekend project and a Fabric Trial F64 capacity. More “official,” larger scale benchmarks executed by the Fabric DW team have been presented at Build and will be available. This is preview. Behavior will change, and your mileage will vary by workload. TPC-H is analytical and read-heavy — exactly where GPUs shine. If your workload is small, low-concurrency, or transactional, plain CPU execution is still sufficient, and you don’t need this. My benchmark noise (see the 256-user run) is a reminder that one run is an anecdote. Run your own workload before drawing conclusions. But for the case GPUs are built for — high-concurrency analytical queries — the gap isn’t marginal. It’s the difference between a 15-second p95 and a 97-second one. Intrigued? Learn more about it in our deep-dive blog post, A new analytics frontier: GPU-accelerated Fabric Data Warehouse, and and request access to the preview to try it with your own workload.
