An engineer who previously worked with Azure Synapse Analytics dedicated SQL pools wants to define a hash distribution key on a large Fabric Warehouse fact table to control how its rows are distributed across compute nodes, the way they used to in Synapse. What should they understand about doing this in a Fabric Warehouse?
Select an answer to reveal the explanation.
Short Explanation
Bringing a Synapse-dedicated-pool habit into Fabric is like showing up with a stick shift mindset to drive an automatic — the manual gear you're reaching for just isn't there anymore, because the engine handles that job for you now. Fabric Warehouse manages data distribution itself instead of exposing a hash-distribution key to configure. The performance lever that's actually in your hands is things like keeping statistics fresh, not picking a distribution column.
Full Explanation
Fabric Warehouse is architecturally different from a Synapse dedicated SQL pool: dedicated pools required engineers to explicitly choose a distribution strategy — hash, round-robin, or replicated — at table-creation time to control how rows spread across compute nodes, whereas Fabric Warehouse manages data placement and distribution automatically as part of its underlying engine, without exposing an equivalent manual distribution-key setting. Coming from a DP-203-era Synapse background, an engineer might reasonably expect a familiar distribution knob, but the actual, current performance levers available in a Fabric Warehouse look different — keeping statistics current so the optimizer plans well, structuring queries efficiently, and using table-maintenance features are the tools that matter. The claim that hash distribution is configured identically to Synapse using the same syntax is incorrect precisely because the manual concept doesn't carry over. Requiring a hash key before a table can be queried through the SQL analytics endpoint isn't accurate either — Fabric Warehouse tables are queryable without any such manual distribution setup. And distribution configuration was never a Lakehouse Spark setting in either platform — Synapse's distribution keys were T-SQL, dedicated-pool concepts, not Spark ones, so routing that expectation through Spark settings doesn't make sense in either architecture. A caveat: automatic distribution management doesn't mean performance tuning disappears — it just shifts to different levers than the ones a Synapse veteran might reach for first. A concrete check: review current Fabric Warehouse table-creation syntax and confirm there is no distribution-key clause to set, then focus tuning effort on statistics and query structure instead.