Microsoft’s Fabric GPU Warehouse Bet Hits a Five-Region Waitlist

Microsoft put NVIDIA GPUs inside Fabric Data Warehouse and still makes most tenants wait for them. Query acceleration, announced at Build on June 2, 2026, remains a limited preview in five Azure regions.

The wager is specific. Agent apps issue analytical SQL in the inner loop of a conversation, so warehouse latency under concurrency becomes the product. Microsoft is putting silicon on that path, then charging a higher capacity meter when the toggle is on.

Microsoft Is Betting Agents on Warehouse Latency

Arun Ulag, executive vice president of Azure Data, framed Build around a bottleneck that is no longer model quality. Agents, he wrote, restart from zero on business context unless data, rules, and identity sit in one place. Fabric is that place in Microsoft’s telling, and the warehouse is the engine that has to answer while several agents query at once.

GPU query acceleration is the hardware half of that pitch. Eligible joins, aggregations, and scans offload to a GPU coprocessor on the same compute node as the CPUs, with no query rewrite, schema change, or extra copy of the data in OneLake. Microsoft’s internal tests, described around Build, put the headline at up to 7x faster than three unnamed cloud warehouses on reporting and application workloads at 64-user concurrency.

NVIDIA is inside the runtime, not beside it. Custom CUDA kernels sit in the warehouse engine. Ian Buck, NVIDIA’s vice president of hyperscale and HPC, tied that choice to agents rather than dashboards.

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.

Ian Buck, Vice President of Hyperscale and HPC, NVIDIA

GPU databases are not new. HeavyDB, once MapD and OmniSci, ran SQL on GPUs for years, and research engines such as BlazingSQL sat on NVIDIA’s RAPIDS stack. Microsoft’s claim is narrower: a fully managed cloud warehouse that applies GPU execution behind ordinary T-SQL. The CoddSpeed paper, which won SIGMOD’s industry award, says that engine is about twice as fast as HeavyDB on the TPC-H slice the authors measured.

The Preview Still Lives in Five Regions

Build promised early access within weeks. By July 7, 2026, Bogdan Crivat, a Microsoft corporate vice president who leads Fabric’s analytics engines, was already running the feature on a commercial F64 trial and said limited availability was “primarily due to GPU availability.”

Microsoft Learn’s query-acceleration article, last updated August 12, 2026, still calls the feature a limited preview. Tenants request access through a first-come, first-served registration form. After approval, a workspace toggle turns it on for every warehouse and SQL analytics endpoint in that workspace. The toggle cancels queries that are already running.

During the current preview, capacities must sit in one of five regions: East US, East US 2, South Central US, South East Asia, and Germany West Central. Anyone outside those regions has to stand up capacity there. That is a migration tax dressed as a preview rule, and it is how GPU scarcity shows up in a SaaS warehouse.

THE ROLLOUT CLOCK

1. June 2, 2026: Microsoft Build announces GPU-accelerated Fabric Data Warehouse, with early access preview promised in the coming weeks.
2. July 7, 2026: Crivat publishes an F64 trial run and says the feature is in limited availability because GPUs are scarce, not because the code is hidden.
3. August 12, 2026: Learn documentation still lists limited preview, the five regions, and a separate, higher CU meter.
4. September 28, 2026: FabCon and SQLCon in Barcelona ship Fabric Apps and database-hub updates. Query acceleration is not moved to general availability in that round.

Practitioner walkthroughs in late September still treat GPU acceleration as a deep-dive topic, which is what a gated preview looks like from outside the waitlist. Partner posts in June repeated the 7x line. Public customer write-ups that reproduce the three-vendor comparison have not followed.

Three Tests, Three Different Speedups

Three number sets now travel with this feature, and they do not measure the same thing. Mixing them is how a waitlist product turns into a 30x poster.

THE SPEED CLAIMS, SIDE BY SIDE

The 7x figure is Microsoft versus other clouds at a chosen concurrency. The 6x figure is GPU versus CPU inside Fabric on one trial SKU. The 7.9x figure is a lab GPU versus Fabric’s own CPU engine with warm caches. Keep them in those boxes.

The F64 Trial on Commercial Hardware

Crivat ran the full 22-query TPC-H set on parquet in OneLake, with the client in the same Azure region as the capacity. He disabled result-set caching on purpose. On a single connection, every GPU query finished under 500 milliseconds. The slowest, Q21, averaged 444.8 ms. The fastest, Q6, averaged 140.3 ms. He put the CPU median for the same single-user pass at about 1.6 seconds. A sequential TPC-H suite finished in 5.02 seconds on GPU.

Concurrency is where the curves split. At 64 users, CPU throughput was 3.70 queries per second and GPU throughput was 111.4. At 1,000 users, CPU rose only to 16.9 queries per second while GPU held 101.4 q/s versus 16.9 q/s. Median latency at that load was 42.8 seconds on CPU and 8.1 seconds on GPU. The p95 sat at 97.7 seconds on CPU and 15.1 seconds on GPU, the gap between a dashboard that looks wedged and one that still paints.

Crivat’s pricing argument is capacity, not a multiplier on one query. Matching GPU throughput on CPU, he wrote, would take something like an F384 if scaling were linear, and the CPU column in his table does not scale linearly. He also said the 256-user GPU sample was noisy, and he left the ugly row in. That is the run a customer can try to reproduce, on a trial SKU, with one workspace toggle.

The GPU-acceleration earns its money under load, not at the desk of one analyst running one query.

Bogdan Crivat, Corporate Vice President, Microsoft, Fabric Updates Blog

He called that 6x the throughput from the same capacity, flipped on with one control. Light warehouses, he said, should stay on CPU because it is cheaper. Monday-morning dashboards and agent fleets change the math.

Lab Numbers the Preview Does Not Ship

CoddSpeed is the engine name. Matteo Interlandi, a principal scientist manager in Azure Data, described a multi-year path from Tensor Query Processor, a research prototype that expressed SQL operators on PyTorch tensors, into custom CUDA for production null and overflow behavior. Two thin layers sit between Fabric and the chips: a coprocessor abstraction that offloads plan fragments, and a data abstraction that hides NVLink, InfiniBand, and PCIe behind one cache-and-shuffle API.

The paper, which took the Best Industry Paper Award at SIGMOD 2026, reports speedups against CPU Fabric, not against Snowflake. An internal 300 GB customer workload of 16 queries hit 14.9x warm and 9.7x cold. An H100 was about 50% faster than an A100, in line with HBM bandwidth. Scale-out is the caveat that belongs in any agent pitch: eight H100s on TPC-H at scale factor 1000 managed only 2.1x without the data layer, then 27.1x with NVLink in the shuffle path. Two nodes with 16 H100s reached 30.4x. Those racks are not what an F64 trial toggle provisions.

Lessons the team wrote down are conservative. Integrate accelerators beside the existing engine. Push large fragments, because PCIe is not free. Abstract the network or the bottleneck simply moves. Use research frameworks to start, then write kernels. Operator coverage decides how much of a real T-SQL plan stays on GPU before the CPU fallback fires.

How Query Acceleration Gets Billed

The preview is not a free turbo button. Learn says query acceleration uses Fabric capacity units on a separate meter that burns CUs at a higher rate than baseline warehouse work. That charge applies only after the feature is enabled. Once it is on, every query in the workspace bills through the acceleration meter, including queries the GPU never touches.

Gains are also selective. Microsoft says larger scans, typically up to about 1 TB, are the queries most likely to benefit. The path is read-heavy analytics. Writes do not get the GPU. Two type choices still knock plans off the fast path.

WHAT STILL FALLS BACK TO CPU

• Writes: Inserts, updates, and other write operators stay on CPU, so mixed agent pipelines only accelerate the SELECT side.
• nvarchar columns: Support is limited; Microsoft tells teams to prefer varchar(8000) when they can, which is a real schema conversation in warehouses that standardized on Unicode.
• Case-insensitive collations: Support is limited; case-sensitive collations raise eligibility, which collides with a lot of existing T-SQL.
• Ineligible fragments: The optimizer offloads what it can and keeps the rest on CPU, so a plan can be partly accelerated and still bill at the higher meter.

Monitoring is built in. The Fabric portal adds a Query Acceleration column in query history and counts of accelerated runs on long-running and frequent queries. Query insights views expose an is_accelerated flag. SSMS can show a Query Acceleration operator in the graphical plan. That instrumentation is how a team finds out the toggle is on and the GPU is idle, which will be a common first week.

Rayfin, HorizonDB, and the Rest of the Stack

The warehouse GPU is one piece of a Build bet that agents should not only query Fabric, they should live there. Microsoft shipped an open-source SDK and CLI called Rayfin so developers, and coding agents, define data models, APIs, identity, and access policy in code, then deploy a managed backend onto Fabric. App data lands in OneLake, which is how a vibe-coded prototype becomes another governed dataset next to the warehouse.

Crivat built his TPC-H load tool with Rayfin, which is a neat loop: the app platform stress-tests the warehouse it is supposed to sit on. Replit is a launch partner. Amjad Masad, Replit’s CEO, said agents write the code and Fabric ships it, with the path from idea to production measured in hours. FabCon Europe in late September added data connectors for warehouses, lakehouses, SQL databases, and semantic models, plus PostgreSQL as a transactional store for Fabric Apps. The CLI is on npm. The runtime is still a preview application layer, not a replacement for a decade of service code.

Azure HorizonDB is the operational database in the same keynote. Ulag described a PostgreSQL-compatible database still in preview, with storage that scales to 128 TB, compute up to 3,072 vCores, and sub-millisecond multi-zone commit latency. Vector search, model management, and hooks into Microsoft Foundry sit in the same service. Mohsin Shafqat, director of software engineering at Nasdaq, said the draw was transactional data, vectors, and AI functions in one platform instead of a stitched set of parts. HorizonDB had been previewed at Ignite in November 2025 and went public preview at Build. Learn still listed it as preview in September, which puts the OLTP side of the agent stack on the same clock as the warehouse GPU: usable, not generally available.

Fabric IQ, the semantic layer meant to give agents shared business meaning, did go generally available at Build. Intelligence on top of a warehouse that five regions can accelerate is an odd split. The ontology is GA. The engine Microsoft wants sitting under interactive agents is not.

Snowflake Speeds Queries Without a Warehouse GPU

Rivals did not answer with a managed GPU warehouse. Snowflake’s Query Acceleration Service, a CPU burst layer, switched to on-by-default for new Gen2 and multi-cluster warehouses in May 2026. Snowflake said internal 2025 data showed an average 42% improvement on eligible work, and it extended the service into more DML, dynamic-table refresh, and unloads. Adaptive warehouses, aimed at the same “stop sizing clusters” job, were rolling through a handful of AWS regions. Databricks still sells Photon for SQL and GPUs for training, which is a different SKU than a T-SQL coprocessor inside the warehouse.

That gap is real and smaller than a keynote slide. Microsoft is first among the big managed warehouses to put NVIDIA execution behind ordinary SQL. It is also first to make warehouse performance a function of the same GPU supply that already rations training clusters. Crivat had to hunt for a region before he could run TPC-H like a customer. Learn still asks everyone else to join a queue.

The checkable number on an F64 is 101.4 queries per second versus 16.9, with p95 down from 97.7 seconds to 15.1, on 100 GB of TPC-H with the cache off. The 27.1x lab figure needs NVLink in the shuffle path. The 7x vendor figure is Microsoft’s internal comparison at 64 users. Teams that flip the toggle will pay the higher CU meter for every query in the workspace, including the ones that stay on CPU because of nvarchar, a write, or a collation.

Microsoft asked customers to flip a workspace switch and let GPUs sit under T-SQL they already run. Those GPUs are still handed out by waitlist, in five regions, on a dearer meter, while the paper that describes the engine already has a SIGMOD award on it.