Fabric Warehouse GPU query acceleration

Key insights

• Turn on query acceleration in workspace settings under Data Warehouse.
• The setting applies to every SQL endpoint and warehouse in the workspace.
• Joins and aggregations are among the query patterns most likely to benefit.
• Query Insights and the Query Acceleration operator can help identify accelerated work.
• Unsupported operations can run on CPU; writes to disk are not made faster by GPU acceleration.

Microsoft Fabric Data Warehouse GPU query acceleration runs supported parts of SQL queries on GPUs, while CPU execution handles work that cannot be accelerated. It matters to Fabric warehouse developers, data engineers, architects, and capacity admins evaluating query speed, concurrency, or cost. Reza Rad (RADACAD) [MVP] demonstrates the workspace setting and discusses the execution model with Microsoft guests Maraki Ketema and Conor Cunningham.

What's new

GPU acceleration adds another execution path to Fabric Data Warehouse: the warehouse can send suitable fragments of a query to GPUs attached to its back-end nodes. The front end continues to receive the query and distribute work across the warehouse. This is not an instruction to rewrite T-SQL for GPU programming; the feature works within the existing warehouse query engine.

Execution is hybrid rather than all-or-nothing. Supported sections can run on a GPU, while unsupported sections stay on CPU. The transcript describes fallback to CPU if a GPU section encounters a problem, such as a device memory issue or overflow. That makes the execution plan important: the GPU may accelerate part of a query without accelerating every operator.

The video description gives benchmark figures of 3x, 6x, and 7x, depending on concurrency. Those figures are not a promise for an individual warehouse. In the discussion, the guests emphasize query shape, operator support, and data model design as factors that affect results. Treat a benchmark number as a reason to test your workload, not as a forecast for every report or application.

Who it is for and what you need

This capability is aimed at teams running analytical queries in Fabric Data Warehouse, particularly workloads that summarize large amounts of data. The guests identify joins and aggregations as query patterns that tend to gain the most. This can make the feature relevant to report-serving or application workloads where query latency matters, including systems that serve analytics agents.

The transcript does not state a required Fabric license, capacity size, specific supported region, or preview or general availability status. It also does not provide a confirmed general availability date. The discussion says the product team is working toward general availability, but gives no timeline, so check current Microsoft product documentation and your tenant before making deployment plans.

The setting is configured at the workspace level, and the demonstration says it applies to every SQL endpoint and warehouse in that workspace. That scope is worth considering before enabling it: the control described is not limited to a single warehouse or a selected workload. Workload-level controls are mentioned as something the team is looking into, not as a current control shown in the demonstration.

How it works

1. Open the workspace settings and find Data Warehouse.
2. Turn on Query acceleration. In the demonstration, the setting then applies across the workspace to its warehouses and SQL endpoints.
3. Run a representative query and inspect its execution. Queries heavy in joins or aggregations are sensible candidates to test, but their actual performance depends on the query and data model.
4. Use Query Insights to check which queries were accelerated. For frequently run queries, the discussion says Query Insights can show a total count of accelerated runs.
5. Inspect the execution plan for the Query Acceleration operator. The operator marks where the plan separates work that is accelerated from work that was not; in the plan discussed, work after the operator is accelerated, while work before it is not.

The plan can also help explain why a query did not gain as much as expected. If an operation is unsupported, the plan can show it outside the accelerated portion. The guests say the warehouse supports many traditional relational operators, but not every T-SQL built-in function is implemented for GPU execution. They give substring as an example of a scalar function and describe support as expanding over time.

GPU acceleration does not speed up disk writes. For an INSERT INTO … SELECT operation, the select portion may benefit, but the write itself does not. The discussion suggests that teams with medallion-style layers might begin by evaluating the serving or gold layer, while noting that faster execution in earlier layers could still matter where there is a tight deadline.

Limitations and open questions

Performance depends on the workload. Queries returning very large amounts of data to a client may not gain as much as queries that process large inputs and reduce them through grouping or aggregation. The guests also caution that data model choices matter: a design that uses strings broadly may see different gains than a tighter model. They do not recommend redesigning an application as a prerequisite, but say schema adjustments may help in some cases.

Other details remain unresolved in the material: exact regional availability, licensing and capacity requirements, pricing crossover, and the extent of support for individual operators and functions. The video description lists cost and regions as subjects, but the supplied transcript does not give definitive answers. It also mentions future work on broader operator support, visibility, and workload-level controls; those are areas being considered, not confirmed current capabilities.

For a practical evaluation, compare your own representative queries and concurrency patterns, and use Query Insights and execution plans to confirm whether work was accelerated. Do not assume every query will run faster or that benchmark gains will apply unchanged to your data, query mix, and warehouse design.

Sources

• Reza Rad’s Fabric Insider Episode 27: GPU acceleration in Fabric Data Warehouse

Frequently asked questions

How do I turn on GPU acceleration in Fabric Warehouse?

Open workspace settings, go to Data Warehouse, and turn on Query acceleration. The demonstration says the setting applies to every warehouse and SQL endpoint in that workspace.

Which Fabric Warehouse queries benefit most from GPU acceleration?

The discussion identifies queries heavy in joins or aggregations as likely candidates. Actual gains vary with operator support, query shape, and data model design.

How can I tell whether a Fabric query was GPU accelerated?

Use Query Insights to check accelerated queries and counts for frequently run queries. The execution plan's Query Acceleration operator identifies the boundary between accelerated and non-accelerated work.

Does GPU acceleration speed up Fabric Warehouse inserts?

It does not make disk writes faster. The select portion of an INSERT INTO … SELECT query may benefit, but the write itself does not.