Fabric Data Warehouse: Architecture, Caching, GPU Acceleration, and Best Practices

What Is Fabric Data Warehouse?#

Fabric Data Warehouse is an enterprise-scale relational warehouse built on a data lake foundation, purpose-built for star/snowflake schemas, curated corporate data marts, and governed semantic models for BI ^[S1]. Unlike a traditional dedicated SQL pool bolted onto separate storage, every warehouse table is physically a Delta table — Parquet data files plus a file-based transaction log — the same open format used across all of Fabric ^[S1]. That single choice has a concrete payoff: warehouse data is automatically published to OneLake in Delta format, so Spark jobs, semantic models, and other Fabric workloads can read your tables without an export job or a second copy ^[S1].

Development happens in T-SQL against a large SQL Database Engine surface: full multi-table ACID transactions, materialized views, functions, and stored procedures ^[S1]. Storage and compute are separated, which enables near-instant scaling, and workload management is autonomous — the distributed query engine has no user-facing tuning knobs for the core execution path ^[S1].

The most consequential recent change to this picture is CoddSpeed, a hardware-accelerated execution capability now built into the warehouse engine. Developed by a joint Microsoft Research and product engineering team, it was published as a SIGMOD 2026 Industrial Track paper and won Best Paper — a strong signal that the technique is both novel and production-proven, not an experimental side project ^[S6]. Around it, Microsoft has also been shipping a steady stream of smaller, mostly-preview T-SQL and ingestion features — approximate string matching, a client-side bulk-copy API, wider ALTER TABLE support, and configurable data retention among them — which this article covers with an explicit eye on what's actually generally available versus still in preview or coming soon. The rest of the article covers how the warehouse is built, how to avoid its documented performance pitfalls, and how these newer capabilities change what "fast" and "flexible" mean for T-SQL on Fabric.

Core Concepts#

Delta on OneLake#

Every INSERT, UPDATE, or DELETE appends a JSON entry to the table's Delta transaction log rather than mutating rows in place ^{[S1] [S3]}. Automatic checkpointing periodically summarizes that log into a checkpoint file, so a reader only has to parse the latest checkpoint plus any newer entries instead of the entire log history — this sharply cuts metadata I/O on frequently updated tables ^[S3]. Because the underlying data is immutable Parquet, transaction rollback is fast: the engine simply reverts to the prior file versions rather than undoing individual row changes ^[S3].

Transactions and Snapshot Isolation#

Warehouse transactions use snapshot isolation exclusively — attempts to change the isolation level in T-SQL are silently ignored — and a transaction block can include DDL statements such as CREATE TABLE, plus cross-database reads against SQL analytics endpoints in the same workspace ^[S3]. That immutable-Parquet foundation is also what makes rollback cheap: reverting a transaction means pointing back at prior file versions rather than undoing individual row edits ^[S3].

SQL Analytics Endpoint#

Warehouses, Fabric SQL databases, and lakehouses all automatically provision a SQL analytics endpoint at creation, built on the same engine technology as the warehouse itself ^{[S1] [S5]}. The endpoint gives T-SQL access to items that are not warehouses in their own right, while the warehouse item supplies the full transactional T-SQL surface of a traditional enterprise data warehouse ^[S5].

Cross-Database Queries and Ingestion#

A single T-SQL statement can join multiple Fabric data sources in a workspace with zero data duplication ^[S1]. Data can be loaded through several routes: the COPY INTO command, Data Factory pipelines, Dataflows, Spark bulk writes directly to the Delta tables, or cross-database CTAS / INSERT...SELECT / SELECT INTO ^[S1].

Warehouse vs. Lakehouse#

Choose a warehouse over a lakehouse when the job is enterprise-scale, T-SQL-first work over structured or semi-structured data with minimal setup; choose a lakehouse when Spark is the primary tool over heterogeneous, largely unstructured data. Both run the same underlying SQL engine for T-SQL queries, and either item type can be added to a workspace later ^[S1]. Teams migrating off Azure Synapse Analytics dedicated SQL pools, SQL Server, or other SQL Database Engine platforms can use the Fabric Migration Assistant for Data Warehouse ^[S1].

Storage and compute are separated in the warehouse... and workload management is autonomous: the distributed query engine has no user-facing tuning knobs.

Inference: a recurring architectural pattern worth naming explicitly is the medallion split: Bronze and Silver stay in a Lakehouse for Spark-based ETL, CDC, and feature engineering, while the Gold layer is built either as Lakehouse materialized views or as a Warehouse with T-SQL star schemas that reads the Silver Lakehouse tables via cross-database queries using three-part naming (database.schema.table) — this is a documented pattern, though sourced from a lower-tier practitioner guide, so treat it as a directionally sound default rather than a Microsoft-endorsed prescription ^[S12]. One hard boundary inside that pattern: Spark notebooks cannot write directly to Warehouse tables (there's no Warehouse target for saveAsTable-style writes), so the standard bridge is Spark writing to a Lakehouse table with the Warehouse pulling it in via INSERT...SELECT ^[S12].

How It Works: Architecture and Best Practices#

The Cache Hierarchy#

Reading from the data lake is the dominant I/O cost for warehouse queries, so the engine layers local caches over remote OneLake storage to cut the number of remote reads ^[S2]. Caching is fully transparent and always on: queries cache whatever data they touch, whether it's a warehouse table, a OneLake shortcut, or even a shortcut pointing at non-Azure storage ^[S2]. Users cannot disable, configure, or manually clear this cache — Fabric orchestrates it entirely, and Microsoft notes that disabling it would visibly degrade query performance ^[S2]. It's also distinct from result-set caching, a separate feature that caches completed query results rather than the data being scanned ^[S2].

Rule: don't fight the cache — warm it deliberately before you benchmark. The why: on first access, data is transcoded into a compressed columnar in-memory representation, and anything loaded into memory is also serialized to a local SSD tier that survives eviction ^{[S2] [S4]}. A cold run pays that transcoding cost; a warm run doesn't.

-- Wrong: benchmark a query once and trust the number
SELECT region, SUM(amount) FROM fact_sales GROUP BY region;
-- (first run may include a full cache-cold fetch from OneLake)

-- Right: run once to warm the cache, then measure the second run,
-- and confirm cache-cold vs cache-warm using query insights
SELECT region, SUM(amount) FROM fact_sales GROUP BY region;  -- warm-up run
SELECT region, SUM(amount) FROM fact_sales GROUP BY region;  -- measured run

SELECT request_id, data_scanned_remote_storage_mb
FROM queryinsights.exec_requests_history
ORDER BY start_time DESC;
-- data_scanned_remote_storage_mb = 0  ->  served entirely from cache
-- data_scanned_remote_storage_mb > 0  ->  data was pulled from OneLake this run

Eviction is recency-based: when the cache hits capacity while new data arrives, the objects unused for the longest time are removed first, and because the SSD tier is larger than memory, evicted data typically survives there and rehydrates far faster than a remote refetch ^{[S2] [S4]}. The cache also stays transactionally consistent — DML changes made to storage after data was cached still produce correct query results ^[S2].

Statistics and Cold Starts#

The warehouse and SQL analytics endpoint automatically create and maintain histogram, average-column-length, and table-cardinality statistics that the optimizer uses to cost and choose plans; CREATE/UPDATE STATISTICS remain available for single-column histograms during maintenance windows ^[S3]. A query's first execution can suffer a cold start on several fronts at once: data must be fetched from OneLake into cache, statistics may need generating, and paused compute nodes must resume — typically in under a second, though cold starts can be partial if some nodes or data are already warm ^[S3]. Detecting this reliably means checking queryinsights.exec_requests_history, as shown above, rather than trusting a single run ^[S3].

MPP Execution and Forced Distribution#

The warehouse runs a massively parallel processing (MPP) architecture, but some SQL semantics — TOP, global sorts, final result merging — force single-node execution and surface a "non-scalable operation" warning ^[S3]. When single-node execution isn't semantically required, reduce the filtered dataset first, or override the planner with OPTION (FORCE DISTRIBUTED PLAN) ^[S3].

-- This plan may fall back to single-node execution because of the global TOP + ORDER BY
SELECT TOP 100 customer_id, SUM(amount) AS total_spend
FROM fact_sales
GROUP BY customer_id
ORDER BY total_spend DESC;

-- Force the distributed plan when single-node execution isn't actually required
SELECT TOP 100 customer_id, SUM(amount) AS total_spend
FROM fact_sales
GROUP BY customer_id
ORDER BY total_spend DESC
OPTION (FORCE DISTRIBUTED PLAN);

V-Order, ZORDER, and Data Clustering#

V-Order, a write-time Parquet sorting and compression optimization, is enabled by default on all warehouses to speed reads, at the cost of a small ingestion overhead — and once disabled on a warehouse it cannot be re-enabled ^[S3]. A common pattern is a V-Order-disabled staging warehouse that absorbs heavy ingestion, feeding a V-Order-enabled warehouse used for reads ^[S3]. T-SQL data clustering, specified in CREATE TABLE or CTAS, orders rows along a space-filling curve so similar values across the clustering columns land in adjacent storage; clustering metadata embedded in the manifest at ingestion time lets the engine skip whole files and row groups outside a filter predicate's range, with the benefit growing as the table grows ^[S3].

V-Order and ZORDER are frequently confused with each other but solve different problems: V-Order is the write-time Parquet encoding described above, while ZORDER is a physical file/row-group layout choice applied separately, typically via OPTIMIZE ^[S10]. One tier-6 practitioner source's operational tip for large tables: run OPTIMIZE without ZORDER first for compaction, then run OPTIMIZE ... ZORDER afterward as a separate pass, and partition very large tables so ZORDER processes one partition at a time rather than rewriting the whole table in one operation ^[S10]. Hedge: this sequencing guidance is a community-sourced operational tip, not a documented Microsoft recommendation — validate it against your own table sizes before adopting it as a standing practice.

Zero-Copy Table Clones#

Table clones in Fabric Data Warehouse are zero-copy: only metadata is duplicated while the underlying data files continue to be read from OneLake, so a clone can be created almost instantly ^[S3]. A clone can target a prior point in time within the warehouse's retention window, and it carries over row-level security, column-level security, and dynamic data masking without needing those policies reapplied ^[S3]. Once created, the source and the clone are fully independent — dropping either one does not affect the other ^[S3]. This makes clones a practical tool for point-in-time debugging, pre-migration snapshots, or giving a downstream team an isolated copy of Gold-layer tables without duplicating storage.

Workload Isolation#

By default, Fabric Warehouse compute is split evenly (50/50) into two isolated resource pools: a SELECT pool for read queries and a non-SELECT pool for ETL and ingestion, each scaling independently and neither ever exceeding half of total compute — so ingestion cannot starve reads ^[S4]. Workspace admins can replace this default with custom SQL pools ^[S4]. The warehouse and SQL analytics endpoint also enforce a hard limit of 2,048 user sessions per workspace, returning an explicit error at the ceiling; DMVs show both user and system sessions, since Fabric itself runs many system sessions as a SaaS platform ^[S4].

Rule: use workspace boundaries to scale read concurrency, don't just wait for the session limit. A Fabric workspace is a natural isolation boundary of the distributed SQL compute system, so a recommended scale-out pattern is to expose read-only replicas of hot tables in other workspaces via OneLake shortcuts, spreading read load across multiple SQL engines and raising the effective concurrent-session ceiling ^[S4].

-- In a dedicated read-replica workspace, create a shortcut to the source
-- warehouse's Delta tables in OneLake rather than pointing every BI tool
-- at the same primary warehouse
CREATE TABLE reporting_replica.fact_sales_shortcut
WITH (LOCATION = 'Tables/fact_sales', DATA_SOURCE = onelake_source);
-- Reporting tools query the replica workspace, not the primary --
-- spreading the 2,048-session ceiling across engines

Row-Level Security: Pick the Right Layer#

When data flows to Power BI, row-level security is best enforced at the semantic-model layer rather than in T-SQL, since the two security layers behave differently for downstream reporting; reserve T-SQL-layer row-level security in the warehouse itself for direct warehouse access by non-Power-BI clients ^[S12]. Hedge: this guidance comes from a lower-trust practitioner source rather than official Microsoft documentation, so validate the specific interaction for your reporting stack before relying on it as an architectural rule.

New and Recently-Changed T-SQL Surface#

Microsoft has been shipping a wave of T-SQL additions to the warehouse. Feature maturity varies a lot across this set, so the status label below each item is load-bearing — preview features are not production guarantees and should not be treated as GA in architecture decisions.

Approximate string matching (preview). Four new functions — EDIT_DISTANCE, EDIT_DISTANCE_SIMILARITY, JARO_WINKLER_DISTANCE, and JARO_WINKLER_SIMILARITY — shipped in preview ^[S7]. The _DISTANCE functions return a raw numeric measure of how different two strings are, while the _SIMILARITY functions return normalized scores suitable for filtering, ranking, or grouping against a threshold ^[S7]. A demonstrated pattern uses EDIT_DISTANCE with a small threshold in a WHERE clause to catch spelling variants of the same value — matching "Hongkong" and "Hong-Kong" to "Hong Kong" in existing invoice or order data ^[S7]. The stated intent is moving fuzzy-matching and data-standardization logic that used to live in Pipelines or external tooling directly into T-SQL ^[S7].

-- Preview feature: surface likely duplicate customer names for review,
-- rather than relying on an external data-quality tool
SELECT a.customer_id, a.customer_name, b.customer_id AS candidate_match_id, b.customer_name
FROM dbo.customers a
JOIN dbo.customers b
  ON a.customer_id <> b.customer_id
  AND EDIT_DISTANCE(a.customer_name, b.customer_name) <= 2;

String concatenation operators and UNISTR (preview). The || operator adds ANSI-style string concatenation, and ||= provides a concise append-to-variable form; both are preview ^[S7]. UNISTR, also preview, constructs Unicode string literals from escape sequences and is described as more flexible for complex Unicode strings than functions like NCHAR ^[S7].

Bulk Copy (BCP) API (preview). BCP API is a client-side ingestion path for scenarios where an application produces data in memory and needs to write it straight into warehouse tables, without a file-staging step first — and it is explicitly a preview feature, not GA ^{[S8] [S9]}. The recommended default remains server-side COPY INTO whenever source files can be staged in storage; BCP API targets the different case where staging isn't possible ^[S8]. Application code can call it via the SqlBulkCopy class in C# or SQLServerBulkCopy in Java, and the bcp.exe command-line utility exposes the same bulk-copy model for script-driven, runbook-style imports ^[S8]. The mechanism is straightforward: sending data via batched bulk-copy semantics instead of many single-row INSERT statements is what improves throughput ^[S8].

// Preview feature: bulk-load an in-memory DataTable straight into a
// warehouse table from application code, instead of many single-row INSERTs
using var bulkCopy = new SqlBulkCopy(connection);
bulkCopy.DestinationTableName = "dbo.events_raw";
bulkCopy.BatchSize = 5000;
bulkCopy.WriteToServer(inMemoryEventsTable);

Schema-change improvements. ALTER TABLE operations inside explicit transactions reached general availability, letting column add/drop, constraint changes, and multiple ALTER TABLE statements group into one atomic, all-or-nothing schema change ^[S9]. Separately, a preview ALTER COLUMN capability allows widening numeric, time, string, and binary column types in place, without the full-table-rewrite CTAS that used to be required ^[S9].

Scalar UDFs with procedural logic (preview). Scalar user-defined functions gained preview support for loops and multi-branch IF/THEN/ELSE, while staying composable with CTEs, GROUP BY, HAVING, and ORDER BY in analytical queries ^[S9].

Configurable data history retention (preview). Administrators can set a warehouse's retention window between 1 and 120 days via T-SQL; that single window governs time travel, point-in-time table clones, warehouse snapshots, and in-place restore ^[S9]. Longer windows trade higher storage cost for deeper recovery and historical query range; shorter windows trade recovery depth for lower cost — it's an adjustable setting, not a fixed platform limit ^[S9].

SQL analytics endpoint metadata sync (preview). The endpoint's metadata-sync architecture was rebuilt, in preview and gated behind a workspace setting, to cut data-freshness lag from minutes to seconds for changes originating in Lakehouses and mirrored databases ^[S9].

Inference: one of those coming-soon items — a Lakehouse table health-check stored procedure — has since shipped as sp_get_table_health_metrics, a T-SQL-callable diagnostic exposed through the SQL analytics endpoint that reports Delta file-size and row-count distributions and flags anomalies like excessive small files or missing checkpoints. That capability is documented under the Lakehouse and SQL-database capabilities rather than tagged to the warehouse capability directly, but it's worth knowing about here because it's callable as plain T-SQL from any warehouse-adjacent pipeline, dbt project, or orchestration tool, and it only diagnoses — the SQL analytics endpoint is read-only, so the actual OPTIMIZE/compaction fix still has to run through Spark or the Lakehouse engine.

What Goes Wrong#

Trickle DML. Each small INSERT, UPDATE, or DELETE writes a new Parquet file, producing fragmented row groups, slower scans, higher cost, and more reliance on background compaction ^[S3]. Batch writes instead, and perform updates and deletes in batches rather than row-by-row.

Oversized string types. Declaring varchar(8000) or varchar(max) when the real data is much shorter degrades statistics accuracy and cost estimation; declare varchar(n) sized to the actual data. Spark string columns created without a length are seen by the warehouse as varchar(8000), so this bites teams loading from Spark by default ^[S3].

-- Wrong: declared width far exceeds real data, hurting cardinality estimates
CREATE TABLE dbo.customers (
    customer_id INT,
    email VARCHAR(8000)
);

-- Right: size the column to the real data
CREATE TABLE dbo.customers (
    customer_id INT,
    email VARCHAR(254)
);

Judging performance from a cold first run. First-execution latency bundles cache population, on-demand statistics generation, and compute-node resume — never benchmark off a single uncontrolled run; use queryinsights.exec_requests_history to confirm cache state before trusting a number ^[S3].

Single giant DML delete. One tier-6 practitioner source recommends batching large deletes by partition rather than issuing one large WHERE-clause delete against the whole table, because very large single-transaction deletes can hit Delta transaction log limits ^[S10]. Hedge: the specific limit isn't independently documented in this knowledge base — treat "batch by partition" as a reasonable precaution rather than a documented hard threshold.

Unsupported T-SQL forcing a Direct Lake fallback. A view containing non-deterministic functions or other unsupported T-SQL constructs can force a Direct Lake semantic model to fall back to a slower query path; the fix is to materialize the view and remove the non-deterministic functions from its definition ^[S10].

GPU-Accelerated Execution with CoddSpeed#

CoddSpeed is a hardware-accelerated query execution capability built into the Fabric Data Warehouse engine ^[S6]. The headline practitioner fact is that it requires no query changes: the accelerated path runs transparently under existing SQL, and the engine decides internally which query fragments are eligible for GPU execution — nothing needs to be rewritten or hinted ^[S6].

Under the hood, CoddSpeed's execution engine descends from the Tensor Query Processor (TQP) research lineage, which reformulates relational operators — filter/select, join, group-by, order-by — as operations that run on a tensor computation runtime instead of traditional row- or column-oriented CPU operators ^[S6]. That predecessor research reported executing the full TPC-H benchmark suite on tensor-runtime execution, and separately reported up to roughly 9x speedups on hybrid queries that combine machine-learning model inference with SQL operators, which is the evidence base the productized version builds on ^[S6].

The reported numbers are large and, per the paper, general rather than cherry-picked: the accelerated path outperforms equivalent CPU-only execution by more than an order of magnitude across a mix of production and benchmark scenarios ^[S6]. On the TPC-H benchmark at 1TB scale, the accelerated engine reaches up to roughly a 30x speedup over the non-accelerated baseline ^[S6]. End-to-end SQL-endpoint latency improves further under concurrency — roughly 3x at 1 concurrent user, 6x at 16 users, and 7x at 64 users versus a comparable cloud data warehouse — meaning the accelerated path's advantage grows, not shrinks, under load ^[S6].

A separate Fabric blog post frames the underlying GPU query acceleration itself as a coming-soon capability at time of writing — the engine transparently offloading eligible SELECT operations such as large aggregations, joins, and scans to GPU hardware, again with no query rewrites required ^[S9]. That post's own cited benchmarks report the GPU-accelerated warehouse running up to 7x faster than three unnamed leading cloud data warehouse competitors, and holding near-flat response times across a 22-query, 100 GB workload regardless of whether 1 or 64 users ran it concurrently ^[S9]. Feature-maturity note: this is presented as forthcoming rather than already generally available, so treat the underlying GPU acceleration as a preview/coming-soon capability even though the CoddSpeed research paper describes it as production-proven technology — the paper and the roadmap post describe the same underlying technique at different points in its rollout, and only the paper's benchmarks should be read as describing a shipped, measured system.

Internals#

Architecture & design#

The warehouse's storage and compute separation is what makes near-instant scaling possible: Delta files sit in OneLake independent of the compute pools that read them, and workload management above that layer is autonomous — the engine exposes no user-facing tuning knobs for how queries get scheduled across the SELECT and non-SELECT pools ^{[S1] [S4]}. Compute is statically halved by default between the two pools, and each half scales independently without ever exceeding its 50% ceiling, which is the mechanism that structurally prevents ETL from starving concurrent reads ^[S4].

CoddSpeed layers a second, GPU-aware architecture on top of this SQL engine rather than replacing it. The production system is organized around two abstraction layers: a coprocessor abstraction layer that routes eligible query fragments to accelerator hardware, and a data abstraction layer that unifies caching and data movement across CPU and GPU memory so accelerated and non-accelerated operators can be mixed within a single query plan ^[S6]. This two-layer split is deliberate: the paper describes the design goal as "hardware independence," meaning the same abstraction layering lets the warehouse target GPUs today and extend to other accelerator classes such as FPGAs or ASICs later, without redesigning the query engine or its SQL-facing behavior ^[S6].

How it works internally#

At the storage layer, on first access the engine transcodes data from its file-based format into a compressed columnar in-memory representation; storing each column's values contiguously improves compression and lets an operation on one column skip the others entirely ^[S4]. That columnar layout is also what enables parallel execution across columns, letting the engine exploit multi-core processors when scanning, filtering, and aggregating large datasets ^[S4]. Anything loaded into memory is serialized in parallel to a local SSD disk cache, a larger second tier for data that exceeds memory capacity; because SSD capacity exceeds memory capacity, evicted objects typically survive there, and rehydrating from SSD is materially faster than a remote OneLake fetch ^[S4].

On the write path, a background compaction service automatically merges small Parquet files and removes logically deleted rows; since October 2025 it checks for shared locks held by user queries and waits or aborts rather than committing a conflicting write, though write-write conflicts with explicit user transactions remain possible ^[S3].

CoddSpeed's tensor-computation approach targets PyTorch as its execution runtime, treating it as a hardware-abstraction layer: because PyTorch already supports a range of accelerators, expressing relational operators as tensor operations lets the same operator implementations run across hardware without device-specific rewrites ^[S6]. Data movement between CPU and GPU stages is treated as a first-class architectural concern rather than an afterthought — the paper specifically calls out high-bandwidth interconnects such as NVLink and InfiniBand as necessary to keep cross-device and cross-node data transfer from becoming the bottleneck that erodes the accelerator's gains ^[S6].

Performance characteristics#

The warehouse's cache hierarchy has no published latency numbers in the verified knowledge base beyond "node resume or creation typically takes under one second" for a cold-start compute node ^[S3]. CoddSpeed's numbers are the concrete, sourced benchmark data available for this engine: more than an order-of-magnitude speedup over CPU-only execution across a mix of production and benchmark scenarios, framed by the paper as a general characteristic of eligible workloads rather than an isolated best case ^[S6]; up to roughly 30x on TPC-H at 1TB scale ^[S6]; and SQL-endpoint latency improvements that scale with concurrency — about 3x at 1 user, 6x at 16 users, 7x at 64 users versus a comparable cloud data warehouse ^[S6]. The predecessor TQP research additionally reported up to roughly 9x speedups on hybrid ML-inference-plus-SQL queries, which is the earliest data point in this performance lineage ^[S6]. Separately, the coming-soon GPU acceleration roadmap post's own benchmark reports up to 7x over three unnamed competitors with near-flat concurrency scaling on a 22-query, 100 GB workload ^[S9] — a smaller, differently-scoped test than CoddSpeed's TPC-H figures, so the two numbers describe related but not identical benchmark setups and shouldn't be treated as interchangeable.

Worked Example: Staging-to-Read Pattern with V-Order and Cache-Aware Benchmarking#

Inference: the following scenario assembles verified mechanics into a plausible end-to-end pattern. Every individual step is grounded in a verified claim; the overall scenario framing is the author's synthesis.

A team ingests 500 GB of daily transaction data from upstream CSV files. They want fast analytical reads while keeping ingestion throughput high, and they want to benchmark correctly once the pipeline is live.

Setup:

1. Create a staging warehouse with V-Order disabled — it's on by default, so this is an explicit opt-out that reduces ingestion overhead for the heavy-write staging step ^[S3].
2. Load via COPY INTO using source files sized between 100 MB and 1 GB, spread across many files to maximize parallelism, and run several COPY INTO statements in parallel against different staging tables ^[S3].

COPY INTO staging.transactions_raw
FROM 'https://onelake.dfs.fabric.microsoft.com/.../transactions/2026-07-01/*.csv'
WITH (
    FILE_TYPE = 'CSV',
    FIRSTROW = 2
);
-- Run this in parallel against a second staging table for a second file batch
-- rather than serializing all files through one COPY INTO statement.

3. Move staged rows into the main, V-Order-enabled warehouse using cross-database CTAS or INSERT...SELECT — because both live in Delta on OneLake, no separate export step is needed, and downstream Spark jobs or semantic models can read the result immediately ^[S1].
4. Apply T-SQL data clustering on the fact table's date and region columns during the CTAS so the engine can file-skip on the most common filter predicates as the table grows ^[S3].
5. Before the first production load, clone the empty target schema with a zero-copy table clone to give the QA team an isolated copy to validate against, without duplicating storage or reapplying row-level security policies ^[S3].

Benchmarking correctly:

6. Run the target query twice. Discard the first run's timing and check queryinsights.exec_requests_history for data_scanned_remote_storage_mb: a non-zero value on the first run confirms it was cache-cold, while the second run's zero value confirms it was served from cache ^{[S3] [S2]}.
7. If the workload includes queries with TOP N ... ORDER BY, check the query plan for the "non-scalable operation" warning; if the dataset isn't small enough to justify single-node execution, add OPTION (FORCE DISTRIBUTED PLAN) ^[S3].

Scaling reads:

8. As reporting concurrency grows toward the 2,048-session limit, create a secondary workspace with OneLake shortcuts to the fact tables and redirect a portion of BI traffic there, spreading load across SQL engines instead of scaling one warehouse indefinitely ^[S4].

Inference: because CoddSpeed's acceleration is transparent and workload-triggered rather than something a query author configures, and because the broader GPU-acceleration roadmap feature is still coming-soon per Microsoft's own post, this worked example doesn't include a CoddSpeed-specific step — there is no verified claim describing a user-facing toggle or eligibility check the practitioner can act on directly today.