Synapse Analytics bundles a distributed SQL data warehouse, serverless SQL over the data lake, and Spark into one workspace. With Microsoft Fabric now the strategic center of gravity for new analytics platforms (tomorrow’s post), the honest framing for Synapse in 2026 is: a large installed base running serious warehouses that need running well, and specific scenarios where its dedicated pools remain exactly the right tool. So today is about running it well.

Dedicated SQL Pools: Distribution Is Everything

A dedicated pool spreads data across 60 distributions, and every table chooses how: hash on a column, round robin, or replicated. That choice dominates performance. Hash distribute your large fact tables on a high cardinality column that appears in your join keys, so joins between facts sharing the key are distribution local. Replicate small dimensions (under about 2 GB) so every distribution holds a copy and joins never move them. Round robin is for staging and for tables with no good hash key. The failure you are avoiding is data movement: when two tables join on a column neither is distributed by, the engine shuffles data between distributions at query time, and shuffle is where warehouse performance goes to die. EXPLAIN and the query plan DMVs show ShuffleMove operations explicitly; treat each one on a hot path as a design bug.

CREATE TABLE fact_sales
WITH (
    DISTRIBUTION = HASH(customer_key),
    CLUSTERED COLUMNSTORE INDEX
)
AS SELECT ... ;

CREATE TABLE dim_product
WITH (
    DISTRIBUTION = REPLICATE,
    CLUSTERED COLUMNSTORE INDEX
)
AS SELECT ... ;

Columnstore health is the second lever: rowgroups want to be full (around a million rows), and trickle loading creates fragmented rowgroups that quietly halve scan performance. Batch your loads, use COPY INTO or PolyBase for bulk ingestion rather than singleton inserts, and rebuild indexes on tables with poor rowgroup quality. Statistics are the third: auto create helps but update statistics after significant loads, because the distributed optimizer without fresh stats makes distributed mistakes.

Workload Management and Cost Discipline

The pool is a fixed size resource (DWU), and workload management decides who gets it: workload groups reserve resource percentages per query class, classifiers route users and labels to groups, and importance settles queue order. The minimum viable setup is three groups, loads, transformations, and BI, so the CEO dashboard never queues behind the nightly ELT. On cost: dedicated pools bill while running, so pause dev and test pools on schedule, scale down out of hours where the load windows allow, and resist the reflex to scale up before checking distribution design and rowgroup health, because DWU spent compensating for shuffle is the most expensive compute in Azure.

Serverless SQL and Spark

The serverless SQL pool queries files in the lake directly, billed per TB scanned, no infrastructure: ideal for exploration, logical data warehouse patterns over Parquet and Delta, and ad hoc analysis that does not justify pool capacity. Its economics reward the lake hygiene the storage post preached: Parquet over CSV, partition folders matching filter patterns, and file sizes in the hundreds of MB rather than thousands of tiny files. Spark pools round out the workspace for data engineering in notebooks with autoscale and auto pause; keep sessions honest with pause timeouts, because idle Spark clusters are the space heaters of the cloud. For new greenfield platforms, weigh all of this against Fabric, where we pick up tomorrow.

Cheers
Osama