Enterprise data platform guide · updated June 2026
Azure Synapse Analytics: The Enterprise Guide (2026)
Where Synapse fits, where Fabric replaces it, and how to migrate — from the team that built 216+ tenant consolidations, 1,500+ Power BI implementations, and 500+ Microsoft Fabric platforms across 70+ Fortune 500 clients.
Is Azure Synapse still the right choice in 2026, or should I move to Microsoft Fabric?
Azure Synapse remains a supported, production-grade Microsoft data platform in 2026 — there is no end-of-life date. But Microsoft has signaled Microsoft Fabric as the strategic platform for net-new investment. Synapse is the right answer today when you have a tuned Dedicated SQL Pool with stable concurrency, a chargeback model built on DWU sizing, hard sovereign-cloud constraints, or a deep Spark 3.4 + Delta 2.4 lake. Migrate to Fabric when Power BI Direct Lake, OneLake mirroring, Copilot in Fabric, current Apache Spark, or governance / lineage gaps are forcing the decision. The honest path is a sizing-validated assessment before either staying or moving.
Azure Synapse Analytics in 2026 is a supported but maintenance-mode Microsoft data platform. New investment is concentrated on Microsoft Fabric. EPC Group has delivered Synapse and Fabric for 70+ Fortune 500 clients across healthcare, federal, financial services, and life sciences — with 216+ tenant consolidations, 1,500+ Power BI implementations, and 500+ Fabric platforms under a compliance-native delivery model.
Key Facts
Azure Synapse Analytics has no announced end-of-life date as of June 2026, but Microsoft is concentrating new feature investment on Microsoft Fabric
Synapse components: Dedicated SQL Pool (DWU-priced MPP warehouse), Serverless SQL Pool (pay-per-TB scanned), Apache Spark Pool (Spark 3.4 / Delta 2.4), Synapse Pipelines (ADF runtime), Synapse Studio
Microsoft Fabric replaces Synapse with OneLake, Lakehouse, Warehouse, Direct Lake to Power BI, Mirroring, AI Skills, Copilot in Fabric, and Spark 3.5+ / Delta 3.2
EPC Group: 216+ M&A tenant consolidations, 1,500+ Power BI implementations, 500+ Microsoft Fabric platforms
Senior-architect-led, fixed-fee delivery across all six Microsoft Solutions Partner Designations — no offshore handoff
Compliance-native baselines for HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP regulated workloads on Azure Commercial and Azure Government
Synapse vs Databricks: choose Databricks for ML platform depth and Delta Live Tables; choose Synapse or Fabric for Microsoft-native identity, Purview governance, and Power BI Direct Lake economics
Azure Synapse Analytics is one of Microsoft's most consequential enterprise data platforms — a unified workspace that combines a massively parallel data warehouse (Dedicated SQL Pool), a pay-per-query lake engine (Serverless SQL Pool), an Apache Spark engine, and an Azure Data Factory–powered pipeline runtime under one Synapse Studio surface. It is in production at thousands of Fortune 500 organizations and remains a fully supported part of the Azure data estate in 2026.
But the honest read for any data leader evaluating Synapse in 2026 begins with a clear signal from Microsoft: new investment is concentrated on Microsoft Fabric. Direct Lake to Power BI, OneLake mirroring, AI Skills, Copilot in Fabric, Data Activator, and the Fabric Native Execution Engine are Fabric-only and are not being backported to Synapse. The dedicated SQL pool, serverless SQL pool, and Spark pool are operationally stable, but the feature line has stopped moving.
EPC Group's position — informed by 216+ M&A tenant consolidations, 1,500+ Power BI implementations, and 500+ Fabric platforms — is that Synapse is the right answer for specific 2026 workloads (well-tuned dedicated pools with stable concurrency, deep ADLS Gen2 lake investments, sovereign-region constraints), and Fabric is the strategic answer for net-new Microsoft data platforms. This guide gives you the criteria for both decisions, the migration patterns when you choose to move, the cost models for both platforms, and the honest comparison against Databricks. We do not pump either product. We have built both.
What Azure Synapse Analytics Is — The Six Components
Azure Synapse Analytics is best understood as six integrated components inside one Synapse workspace. Each component is a different compute engine, different pricing model, and different operational profile — and the design choice for most Synapse customers is which combination of components delivers the right workload economics. Understanding the boundaries between them is the precondition for any sizing, optimization, or migration decision.
Dedicated SQL pool (formerly SQL DW)
Massively parallel processing data warehouse with provisioned compute measured in Data Warehouse Units (DWUs). Predictable performance, fine-grained sizing, and Polybase-style external tables — the closest thing Synapse offers to a legacy enterprise data warehouse.
Best for: Workloads with stable, high concurrency and known query patterns where pre-aggregated star schemas and resource-class-based concurrency limits deliver predictable SLAs.
Serverless SQL pool
Pay-per-query T-SQL engine that reads Parquet, CSV, JSON, and Delta files directly from ADLS Gen2 without provisioned compute. Ideal for exploratory analytics, ad-hoc reporting over lake data, and lightweight ELT staging without warehouse cost.
Best for: Lake-first architectures where teams need T-SQL access to lake files without standing up a dedicated pool, and for low-frequency reporting where pay-per-query economics beat provisioned compute.
Apache Spark pool
Managed Apache Spark (currently Spark 3.4 in Synapse, with no path to Spark 3.5 or 4.x announced) for data engineering, ML feature engineering, and large-scale data transformation. Notebook-driven, integrated with MLflow, and shares the same workspace storage as SQL pools.
Best for: Synapse-native data engineering teams who built pipelines around Spark 3.4 and Delta 2.4. New Spark workloads in 2026 should be evaluated on Microsoft Fabric Spark, which tracks current Apache Spark releases.
Synapse Pipelines
Azure Data Factory rebranded inside the Synapse workspace — the same Mapping Data Flow runtime, the same Integration Runtime, the same 100+ connectors. Orchestrates ingestion from on-prem SQL, SAP, Oracle, Salesforce, and SaaS sources into ADLS Gen2 and dedicated pools.
Best for: ELT orchestration for Synapse workloads. The runtime is unified with Fabric Data Factory, so pipeline assets carry forward with minimal refactor when you migrate.
Synapse Studio
The single-pane workspace that unifies SQL, Spark, pipelines, monitoring, and Git integration. Provides T-SQL query editing, Spark notebooks, pipeline authoring, and role-based access to a shared workspace identity model under Microsoft Entra.
Best for: Engineering teams who need one workspace for SQL + Spark + orchestration. Note that Microsoft Fabric replaces Synapse Studio with the Fabric workspace experience — same intent, modernized stack.
Linked services & integration runtimes
Synapse uses Azure Data Factory integration runtimes — Azure IR for cloud-to-cloud, Self-Hosted IR for on-prem and private network connectivity, and SSIS IR for lift-and-shift of legacy SSIS packages. Linked services are tenant-scoped credentials reusable across pipelines.
Best for: Hybrid environments where data still lives behind firewalls in SAP, Oracle, AS/400, and legacy SQL Server. The Self-Hosted IR pattern is one of the few areas where Synapse parity with Fabric is still uneven in 2026.
Synapse vs Microsoft Fabric — The Truthful Comparison
The Synapse vs Fabric question is the single most-asked question in Microsoft data platform engagements in 2026. The pump answer is "move everything to Fabric." The honest answer is the comparison below — ten criteria where the architectural, pricing, and roadmap differences matter for an enterprise decision. EPC Group runs this comparison every week for new clients and refreshes it quarterly against the Microsoft Fabric and Azure Synapse roadmaps.
Criterion
Azure Synapse Analytics
Microsoft Fabric
Workspace model
Single Synapse workspace per region. Studio-based authoring. Resource-group bound. Discrete services (SQL pool, Spark pool, pipelines) attached to one workspace.
Multi-workspace, capacity-based. OneLake provides a tenant-wide data lake. Item types (Lakehouse, Warehouse, KQL DB, Semantic Model, Notebook, Pipeline) are first-class artifacts inside workspaces.
Pricing model
Component pricing. Dedicated SQL pool by DWU (100c–30000c). Serverless SQL pool pay-per-TB-scanned. Spark pool by vCore-hour. Pipelines by activity run + integration runtime hour. Storage on ADLS Gen2 priced separately.
Unified Fabric capacity (F2 → F2048) measures all compute — Lakehouse, Warehouse, Spark, Data Factory, Power BI Premium, Real-Time Intelligence, Data Activator — against one capacity unit. OneLake storage included up to capacity allotment.
Apache Spark version
Spark 3.4 / Delta 2.4 as of June 2026. No public roadmap to Spark 3.5 or 4.x in Synapse runtime.
Tracks current Apache Spark — Fabric Runtime 1.3 ships Spark 3.5 / Delta 3.2; Runtime 1.4 preview on Spark 4.0. Native NEE (Native Execution Engine) for vectorized Parquet scans.
Lakehouse support
Lake database via serverless SQL pool over ADLS Gen2 Delta tables. No first-class managed lakehouse item. Manual file management, no V-Order, no automatic statistics refresh.
Lakehouse is a first-class workspace item. V-Order Parquet writes optimized for Power BI Direct Lake. Automatic Z-Order, statistics, and shortcut-based virtualization to ADLS, S3, GCS, and Dataverse.
Mirror databases (zero-ETL replication)
Not supported. Cross-platform data needs ingestion via Synapse Pipelines, change data capture into ADLS Gen2, and downstream materialization.
Mirroring for Azure SQL DB, Azure Cosmos DB, Snowflake, Databricks Unity Catalog, and Azure SQL MI streams operational data into OneLake near-real-time with zero pipeline code and no source-side load.
Direct Lake to Power BI
Not supported. Power BI on Synapse data uses Import mode (with refresh latency) or DirectQuery (with query-time pressure on the dedicated pool). Aggregations help but require maintenance.
Direct Lake reads V-Order Parquet from OneLake directly into the Power BI VertiPaq engine — Import-mode performance with zero refresh, governed by capacity. The single biggest 2026 Power BI advantage of Fabric over Synapse.
Power BI integration depth
Power BI connects to Synapse over standard connectors. Workspace and capacity are managed separately. No native semantic-layer sharing.
Power BI Premium and Fabric capacity are the same SKU. Semantic models, lakehouses, and warehouses share OneLake. Promoted / certified items flow with workspace governance.
Governance (Purview)
Purview catalogs Synapse SQL pools, Spark databases, and ADLS Gen2. Lineage is collected via connectors but is not always populated for Spark notebooks or custom pipelines.
Native Purview integration with end-to-end lineage across OneLake, Lakehouse, Warehouse, Semantic Model, and Power BI. Sensitivity labels and DLP flow with the data through the stack.
Identity (Entra)
Microsoft Entra ID for workspace identity, with SQL pool supporting Entra-authenticated principals and legacy SQL logins. Row-level / column-level security configured per pool.
Tenant-wide Entra identity across workspaces and OneLake. Workspace roles, item-level permissions, OneLake security, and Fabric capacity admin roles unified under a single identity surface.
Microsoft roadmap signal
Maintenance mode. Microsoft will continue to operate dedicated SQL pools, serverless SQL, and Spark pools for existing customers, but new feature investment is concentrated on Fabric. No EOL announced as of June 2026.
Strategic Microsoft data platform for 2026 and beyond. Quarterly capability shipments. Direct Lake, OneLake, Mirroring, AI Skills, Copilot in Fabric, and Data Activator are Fabric-only.
Comparison reflects Microsoft Fabric and Azure Synapse Analytics product state as of June 2026. Sources: Microsoft Learn documentation, Microsoft Fabric public roadmap, EPC Group production deployments across 500+ Fabric platforms and a comparable Synapse customer base. Reviewed for accuracy by senior architects on the EPC Group Data & AI practice.
When to Choose Synapse in 2026 — Four Specific Scenarios
We have walked many clients away from a Fabric migration in 2026 — not because Fabric is the wrong platform, but because the timing or the workload profile makes Synapse the lower-risk, lower-cost answer for another 18–36 months. Below are the four scenarios where Synapse is still the right call. If your situation matches one of these, an optimization engagement on the existing Synapse estate typically delivers better ROI than a migration this year.
Scenario 1
Significant existing Dedicated SQL Pool investment with stable workload patterns
The shape of the workload
A 12-year-old enterprise data warehouse on Synapse Dedicated SQL Pool, 8 TB compressed, DW3000c provisioned, supporting 1,200 concurrent Power BI consumers via Import-mode refresh and DirectQuery aggregations. The star schema is tuned, statistics are healthy, and resource-class concurrency is matched to the user community.
Why Synapse is still the right answer
Migrating to Fabric Warehouse rewrites the cost model from provisioned DWUs to capacity-burst CUs, which can be more expensive at sustained high concurrency. Until you have an FUC (Fabric Unit of Capacity) sizing exercise that proves equal or better economics under your actual concurrency curve, the dedicated pool remains the lower-risk answer. Migrate when you have a sized model, a refactor budget, and a Power BI Direct Lake business case.
Scenario 2
Workloads requiring fine-grained, isolated compute sizing per business unit
The shape of the workload
A holding company with five operating subsidiaries, each running independent dedicated SQL pools at DW400c–DW2000c with strict cost-allocation chargebacks. Each pool is paused / resumed on business-hour schedules, and the cost-allocation model maps cleanly to DWU-hours by subsidiary cost center.
Why Synapse is still the right answer
Fabric capacity is shared across workloads — chargeback becomes a workload-consumption calculation, not a discrete pool size. If your finance team has built a chargeback framework around the dedicated-pool sizing primitive, the migration to Fabric requires rebuilding chargeback first. Plan a 60–90 day FinOps redesign before the platform migration.
Scenario 3
Regional / sovereign cloud constraints where Fabric availability lags Synapse
The shape of the workload
A federal contractor operating in Azure Government Cloud or a regulated workload in a sovereign Microsoft Cloud (e.g., Microsoft Cloud for Sovereignty regions) where Fabric capacity SKUs and OneLake regional residency are not yet generally available or have feature gaps relative to commercial cloud.
Why Synapse is still the right answer
Microsoft is expanding Fabric to Azure Government and sovereign regions on a published roadmap, but parity is staged. For workloads with hard data-residency requirements in regions where Fabric is not yet GA at the SKU and feature level you need, Synapse remains the production answer. Re-evaluate quarterly against the Microsoft Fabric regional roadmap.
Scenario 4
Legacy ADLS Gen2 + Spark 3.4 lake architectures with deep tooling investment
The shape of the workload
A data-engineering organization that built a curated medallion lake (Bronze / Silver / Gold) on ADLS Gen2 using Synapse Spark 3.4, Delta 2.4, Synapse Pipelines, and custom Spark UDFs / Scala libraries. The lake is consumed by serverless SQL pool views and a downstream dedicated SQL pool for aggregated marts.
Why Synapse is still the right answer
Migrating to Fabric Lakehouse is feasible — OneLake shortcuts can virtualize the existing ADLS Gen2 storage in place — but the Spark code, custom libraries, and notebook orchestration need refactor to Fabric Runtime 1.3 (Spark 3.5). For organizations not yet ready to absorb that refactor cost, Synapse remains operationally sound. Plan the migration as part of a broader medallion modernization initiative, not an isolated lift.
When to Migrate Synapse → Fabric — Six Triggers + a Five-Phase Plan
The six triggers below are the conditions that consistently flip an honest Synapse Health Check from "optimize and stay" to "migrate to Fabric." If any two of these are true for your environment in 2026, the migration is typically value-positive within twelve to eighteen months. If four or more are true, you are likely already paying a tax by staying on Synapse.
1
Power BI is the primary consumption surface, and refresh / DirectQuery latency is hurting the business
Direct Lake reads V-Order Parquet from OneLake into the Power BI VertiPaq engine with zero refresh latency. For Power BI–anchored organizations, this is the single highest-impact migration trigger in 2026.
2
You need zero-ETL replication from operational sources into the lakehouse
Fabric Mirroring streams Azure SQL DB, Azure Cosmos DB, Snowflake, Databricks Unity Catalog, and Azure SQL Managed Instance into OneLake near-real-time with no source-side load and no pipeline code.
3
You are consolidating multiple data platforms (Synapse + Power BI Premium + Azure ML) for FinOps reasons
A single Fabric capacity covers Lakehouse, Warehouse, Spark, Data Factory, Power BI Premium, Real-Time Intelligence, ML, and AI Skills. Unifying onto one capacity typically simplifies the FinOps story and reduces SKU sprawl.
4
Your Spark workload needs Apache Spark 3.5+, Delta 3.x, or the Fabric Native Execution Engine
Synapse Spark is pinned at 3.4. Fabric Runtime 1.3 ships Spark 3.5 / Delta 3.2 with the Native Execution Engine for vectorized Parquet scans. If you need current Spark, Fabric is the only path inside the Microsoft data estate.
5
Governance and lineage gaps in Synapse are creating audit findings
Fabric is integrated with Microsoft Purview from inception — end-to-end lineage across OneLake, Lakehouse, Warehouse, Semantic Model, and Power BI, with sensitivity labels and DLP flowing through the stack. Regulated industries typically migrate for this reason alone.
6
You need Copilot in Fabric, AI Skills, or Data Activator
Copilot in Fabric for Data Factory, Notebooks, Power BI, and Warehouse; AI Skills for natural-language analytics; Data Activator for event-driven actions on OneLake data — none of these are available in Synapse and none are roadmapped to Synapse.
The EPC Group Synapse → Fabric Migration Plan (Five Phases)
Every Synapse → Fabric migration EPC Group has delivered follows this five-phase pattern. The phases are sequential, but the discrete workstreams inside them often run in parallel. The 90-day Synapse → Fabric Migration Accelerator engagement is sized against this plan.
Phase 1
Assess
Phase 2
Capacity Sizing
Phase 3
Mirror
Phase 4
Refactor
Phase 5
Cutover
Phase 1 — Assess. Inventory every dedicated SQL pool object, every serverless SQL pool external table, every Spark notebook, and every pipeline. Classify by criticality, refresh cadence, source-to-target dependency, downstream Power BI consumption, and integration runtime type. Map the Microsoft Purview lineage graph. Produce a fixed-fee assessment report with a workload-by-workload migration sequence and a Fabric capacity recommendation.
Phase 2 — Capacity Sizing. Translate the dedicated SQL pool DWU consumption curve, the serverless SQL pool TB-scanned curve, the Spark vCore-hour curve, and the pipeline activity rate into a Fabric Unit of Capacity (FUC) model. Run a Fabric capacity smoothing simulation against your actual 30-day usage telemetry. Size F-SKU recommendation with reserved instance commitment math.
Phase 3 — Mirror. Connect OneLake shortcuts to existing ADLS Gen2 storage in place — no data movement required for cold lake assets. Configure Fabric Mirroring for Azure SQL DB, Azure Cosmos DB, or Snowflake operational sources. Establish the OneLake medallion structure (Bronze / Silver / Gold) that mirrors the existing Synapse lake.
Phase 4 — Refactor. Refactor Spark 3.4 notebooks to Spark 3.5 on Fabric Runtime 1.3. Rebuild custom Scala / Java JARs against Fabric SDK targets. Convert dedicated SQL pool tables to Fabric Warehouse or to Lakehouse Delta tables based on workload profile. Rebuild Power BI semantic models on Direct Lake. Migrate pipelines from Synapse Pipelines to Fabric Data Factory using the workspace migration tool plus targeted refactor for Self-Hosted IR dependencies.
Phase 5 — Cutover. Run Synapse and Fabric in parallel for a documented validation window (typically 30 days, longer for regulated workloads). Reconcile cost telemetry across both platforms. Validate data parity through automated row-count and checksum comparison. Cut consumption surfaces (Power BI, downstream apps) to Fabric. Decommission Synapse components in the inverse order of dependency. Hand off the runbook to your team or to a managed-services retainer.
Synapse vs Databricks — Honest Comparison for the Microsoft-Anchored Enterprise
Databricks is an excellent platform. We say that without hesitation — it ships the strongest production Spark in the market, the most mature lakehouse governance (Unity Catalog), and an industry-leading MLOps platform (MLflow, Feature Store, Mosaic AI). The honest 2026 comparison is not "which platform is better." It is "which platform is the lower-TCO answer for a Microsoft-anchored enterprise" — and that depends on which architectural surfaces you already pay for, which compliance posture you operate under, and which consumption pattern dominates your analytics estate.
Criterion
Azure Synapse (or Fabric)
Databricks
Workspace model
Single Synapse workspace bundling SQL pool, Spark pool, pipelines, and Studio under one Azure resource group.
Workspace + Unity Catalog metastore + multiple clusters. Native multi-workspace federation through Unity Catalog. More mature cross-workspace governance.
Pricing model
Component pricing — DWU-hour for dedicated pool, TB-scanned for serverless SQL, vCore-hour for Spark, integration runtime hour for pipelines, ADLS Gen2 storage separate.
DBU-based pricing across job, all-purpose, and SQL warehouse compute. Photon engine adds ~2x DBU rate but typically delivers >2x performance. Storage on customer-owned S3 / ADLS.
Spark version + engine
Spark 3.4 / Delta 2.4. No vectorized execution engine.
Spark 3.5+ / Delta 4.x with Photon vectorized C++ engine. Delta Live Tables for declarative pipelines. Generally regarded as the strongest production Spark in the market.
Governance
Microsoft Purview connector — lineage and classification across SQL pools, Spark, ADLS Gen2, but lineage completeness for Spark notebooks and custom pipelines varies.
Unity Catalog — first-class data governance, attribute-based access control, fine-grained column / row-level security, native lineage. Generally the most mature lakehouse governance layer.
Identity (Entra)
Native Entra ID for workspace and SQL pool authentication. SQL pool RLS / CLS configured per pool.
Entra ID via SSO and SCIM provisioning, mapped to Unity Catalog principals. Workspace-level access control. Entra is a connected identity, not native.
Power BI integration
Power BI connectors to Synapse SQL pool and serverless SQL. No Direct Lake. Import / DirectQuery only.
Power BI connector to Databricks SQL Warehouses. Direct Lake to Databricks Unity Catalog tables in preview. Import / DirectQuery / Direct Lake supported, but with cross-platform identity and governance considerations.
MLOps / ML platform depth
Notebook-based ML via Synapse Spark + MLflow. Azure ML integration available but separate service. Limited end-to-end MLOps inside the Synapse workspace.
Industry-leading. MLflow native. Model Registry, Feature Store, Mosaic AI, AutoML, real-time serving. The clearest area where Databricks beats Synapse / Fabric for ML-heavy organizations.
Total cost of ownership (Microsoft-anchored enterprise)
Lower TCO for organizations already on Microsoft 365, Power BI Premium, Azure landing zones, and Microsoft Entra — because identity, governance, and BI consumption costs are amortized across the existing estate.
Higher per-workload compute efficiency for heavy Spark / ML, but typically higher TCO when you factor in separate governance (Unity Catalog), separate identity federation, separate Power BI semantic layer, and separate cost-management tooling.
Where Synapse / Fabric wins
✓Microsoft-anchored identity (Entra), governance (Purview), and BI (Power BI Direct Lake) under one platform
✓Lower TCO when amortized across an existing Microsoft 365 + Power BI Premium + Azure estate
✓Native integration with Dynamics 365, Power Platform, Microsoft Purview, and Microsoft Defender for Cloud
✓Compliance posture that maps cleanly onto Microsoft Cloud for Government, sovereign clouds, and regulated frameworks (HIPAA, FedRAMP High, CMMC 2.0)
✓Single-vendor accountability for the full data + BI + AI stack
Where Databricks wins
✓Strongest production Apache Spark in the market — Photon engine, Delta Live Tables, current Spark / Delta releases
✓Industry-leading MLOps and AI platform — MLflow, Feature Store, Mosaic AI, AutoML, real-time model serving
✓Multi-cloud portability — same platform on Azure, AWS, GCP — preferred where regulatory or strategic cloud-neutrality matters
✓Better choice when ML platform depth or heavy Spark workload economics are the dominant decision criteria
EPC Group has delivered both Synapse / Fabric and Databricks for Fortune 500 clients. Many of the most sophisticated enterprises run both — Databricks for heavy ML and Spark workloads, Fabric for Power BI consumption and Microsoft 365 integration — connected through Fabric mirroring to Databricks Unity Catalog tables. The honest answer for your enterprise depends on workload profile, not vendor loyalty.
Azure Synapse Pricing — DWU, TB-Scanned, vCore-Hour, and Three Realistic Scenarios
Synapse pricing is component-by-component and therefore non-trivial to forecast accurately. The three pricing primitives — Dedicated SQL Pool DWUs, Serverless SQL Pool TB scanned, and Spark Pool vCore-hours — each behave differently under load. The estimates below are list-price U.S. East at June 2026 for representative enterprise workload shapes. Real engagements typically land 15–35 percent below list with Microsoft EA discounts, reserved instance commitments, and dev/test SKU substitutions.
Dedicated SQL Pool (DWU)
Provisioned MPP compute measured in Data Warehouse Units (DWU). Sizing bands from DW100c through DW30000c, billed per hour while running, with pause / resume control. Pricing scales roughly linearly with DWU — DW1000c costs ten times DW100c, with proportional concurrency and query throughput.
Indicative list pricing: DW100c ≈ $1.20/hr, DW1000c ≈ $12.00/hr, DW7500c ≈ $90.00/hr, DW30000c ≈ $360.00/hr. Reserved instance commitments deliver up to ~37 percent discount on a three-year term.
Serverless SQL Pool (pay-per-query)
No provisioned compute. Billed per terabyte of data scanned from ADLS Gen2 — Parquet, CSV, JSON, or Delta — by T-SQL queries against external tables or OPENROWSET reads.
Indicative list pricing: ~$5.00 per TB scanned. Parquet (columnar) scans are dramatically cheaper than CSV (row-based) for the same logical query. Cost discipline depends entirely on disciplined file-format selection (Parquet, partitioned), partition pruning, and column projection.
Apache Spark Pool (vCore-hour)
Billed per vCore-hour while a Spark session is active. Pool sizes from Small (4 vCores) through XXLarge (64 vCores) per node, with auto-scale and auto-pause. Spark 3.4 / Delta 2.4 runtime.
Indicative list pricing: ~$0.19 per vCore-hour for Memory Optimized nodes. A 6-vCore Spark pool running 16 hours/day lands around $550–$650/month before any custom-library overhead.
Synapse Pipelines + Integration Runtimes
Pipelines billed per activity run (~$1 per 1,000 activity runs) plus integration runtime hours. Azure IR ≈ $0.25/hr per DIU (Data Integration Unit). Self-Hosted IR has no per-hour Microsoft cost but requires customer-managed compute.
Typical mid-enterprise pipeline footprint with 25–50 daily pipeline runs and a Self-Hosted IR for on-prem sources lands in the $1,500–$3,500/month range.
Three Realistic Enterprise Pricing Scenarios
Scenario 1
Small departmental warehouse
Workload profile: DW100c dedicated SQL pool paused outside business hours (10 hours/day, 22 business days/month), 500 GB serverless SQL pool queries/month, 1 small Spark pool burst weekly, 3 pipelines daily, 2 TB ADLS Gen2 storage.
Estimated monthly cost: Approximately $3,200–$4,800 per month at U.S. East list pricing — dominated by dedicated SQL pool compute (~$1,800), serverless SQL pool pay-per-query (~$250), Spark and pipeline costs (~$400), and ADLS Gen2 storage and egress (~$150).
Scenario 2
Medium enterprise warehouse + lake
Workload profile: DW1000c dedicated SQL pool running 16 hours/day, 5 TB serverless SQL pool scans/month, medium Spark pool with 6 vCore × 16-hour daily runs, 25 pipelines/day, 50 TB ADLS Gen2.
Estimated monthly cost: Approximately $28,000–$42,000 per month at U.S. East list pricing — dominated by dedicated SQL pool (~$22,000), Spark compute (~$6,000), serverless SQL pool (~$2,500), pipelines and runtime (~$1,500), and ADLS Gen2 storage (~$1,200).
Scenario 3
Large enterprise warehouse
Workload profile: DW7500c dedicated SQL pool always-on for global concurrency, 30 TB serverless SQL pool scans/month, large Spark pool 24×7 at 12 vCores, 200 pipelines/day with Self-Hosted IRs for on-prem SAP and Oracle, 500 TB ADLS Gen2.
Estimated monthly cost: Approximately $185,000–$245,000 per month at U.S. East list pricing — dominated by always-on DW7500c (~$165,000), Spark compute (~$28,000), pipelines and integration runtimes (~$8,500), serverless SQL pool (~$15,000), and ADLS Gen2 storage (~$12,000).
Estimates are illustrative June 2026 list-price models for planning conversations — not commercial quotes. Real pricing depends on region, Microsoft EA discounts, reserved instance commitments, dev/test substitutions, and actual workload telemetry. EPC Group's Synapse Health Check produces a sized cost model against your actual usage curve.
For regulated and enterprise customers, the governance baseline frequently outweighs the compute decision. Azure Synapse Analytics integrates with the same Microsoft governance and security surface that applies across Azure — but the implementation choices and the gaps relative to Microsoft Fabric matter for design. EPC Group's standard Synapse governance pattern covers seven controls.
Microsoft Purview integration
Catalog Synapse SQL pools, Spark databases, and ADLS Gen2 from a single Purview account. Configure scheduled scans, automatic classification with built-in and custom classifiers, and lineage collection. Honest gap: Purview lineage completeness for custom Spark notebooks and complex pipeline DAGs is uneven — manually annotate critical lineage edges.
Microsoft Entra identity
Workspace identity, SQL pool authentication, and serverless SQL pool access all flow through Microsoft Entra ID — including conditional access, multi-factor authentication, and Privileged Identity Management (PIM) for workspace administrators. Disable legacy SQL authentication unless a specific service requires it; if so, scope the SQL login tightly and rotate via Key Vault.
Row-level security (RLS) and column-level security (CLS)
Native to Dedicated SQL Pool — RLS via security predicates, CLS via column-level GRANT / DENY. Centralize policy definition in version-controlled DACPAC deployment so that security policy ships with the schema and survives pool restores.
Dynamic data masking
Mask sensitive columns (SSN, account numbers, dates of birth) at query time without changing the underlying data. Combine with Purview sensitivity labels to auto-propagate mask rules across tables sharing a classification.
Customer-managed keys (CMK) with Azure Key Vault
Transparent Data Encryption (TDE) on Dedicated SQL Pool with customer-managed keys stored in Azure Key Vault or Azure Key Vault Managed HSM. Required baseline for HIPAA, FedRAMP High, GxP-validated, and many financial-services governance frameworks. Pair with automated key rotation and Key Vault firewall enforcement.
Private endpoints and network isolation
Lock the Synapse workspace, dedicated SQL pool, serverless SQL pool, and ADLS Gen2 storage behind private endpoints with Azure Private Link. Use Managed Virtual Network and Managed Private Endpoints for outbound connectivity to data sources. Disable public network access at the resource level.
EPC Group delivers Synapse and Fabric governance under data governance engagements aligned to the named regulatory baseline — HIPAA, SOC 2, FedRAMP High, FINRA, CMMC 2.0, GxP — with documented control mapping suitable for regulator and auditor review.
EPC Group's Data Platform Credential Stack
The honest decision framework above is not theoretical. It is the working model behind every Synapse and Fabric engagement EPC Group has shipped — across 70+ Fortune 500 clients, 216+ M&A tenant consolidations, 1.83 million users migrated, and a 29-year operating history on the Microsoft cloud since 1997.
11,000+
Microsoft engagements over 29 years
1,500+
Power BI implementations
500+
Microsoft Fabric platforms
216+
M&A tenant consolidations
Microsoft Press authorship on Power BI and Microsoft data platforms
Founder and CEO Errin O'Connor is a four-time Microsoft Press bestselling author, with titles covering Power BI, SharePoint, Azure, and large-scale enterprise migrations — the same architectural patterns that inform every Synapse and Fabric engagement we deliver. Power BI expertise hub →
All six current Microsoft Solutions Partner Designations
Data & AI, Modern Work, Infrastructure, Security, Digital & App Innovation, Business Applications — full coverage of the Microsoft cloud stack with no subcontracting. The Data & AI Designation is the named credential behind every Synapse and Fabric engagement.
The EPC Group Lifecycle — Assess → Modernize → Govern → Operate → Enable
The named, single-accountable-partner delivery model that lets the same senior architects own a Synapse or Fabric engagement from board roadmap through year-two managed operations. No phase-to-phase team rotation. See the full Lifecycle →
Synapse and Fabric engagements delivered with documented control mapping to the named regulatory baseline — zero audit findings across the regulated industries EPC Group serves. U.S.-citizen-only delivery teams available for federal and CMMC 2.0 engagements.
Three Engagement Models for Synapse and Fabric
EPC Group structures Synapse and Fabric engagements three ways. Most customers enter through a Synapse Health Check, then move into a Migration Accelerator if the diagnosis supports it, then into Managed Synapse + Fabric Co-Pilot for steady-state operations. Health Check and Migration Accelerator pricing is fixed-fee — known before delivery starts.
2-week fixed fee
Synapse Health Check
Senior-architect-led assessment of the current Synapse estate — dedicated SQL pool sizing efficiency, serverless SQL pool query cost analysis, Spark workload performance, pipeline observability, governance posture under Microsoft Purview, identity and RBAC review, and a fixed-fee report with a Fabric migration readiness scorecard and a 12-month optimization roadmap.
Best for: Synapse customers who need an honest read on whether to optimize, stay, or migrate — without committing to a delivery program before the diagnosis is complete.
90-day fixed fee
Synapse → Fabric Migration Accelerator
Five-phase migration delivery — Assess (FUC sizing, workload inventory), Capacity Sizing (Fabric capacity model under real load), Mirror (OneLake shortcuts + mirroring for ADLS Gen2 and operational sources), Refactor (Spark 3.4 → 3.5 / Direct Lake semantic models / Pipelines → Fabric Data Factory), and Cutover (parallel-run validation, cost reconciliation, runbook handoff). Compliance-native delivery aligned to your regulatory baseline.
Best for: Organizations ready to move Synapse to Fabric inside a calendar quarter — typically because Power BI Direct Lake, AI Skills, Copilot in Fabric, or governance / lineage requirements are forcing the migration.
Monthly retainer
Managed Synapse + Fabric Co-Pilot
24/7 co-managed operations across the Synapse and Fabric estate — capacity tuning, dedicated SQL pool optimization, serverless SQL cost monitoring, Spark workload management, pipeline observability, Direct Lake semantic model maintenance, Purview lineage health, Entra access reviews, and a named senior architect on retainer with monthly executive reporting.
Best for: Organizations running Synapse and Fabric in parallel during a multi-quarter migration, or production-scale Fabric customers who need senior-architect bench depth without hiring it full-time.
Synapse and Fabric Under the EPC Group Lifecycle
Every Synapse or Fabric engagement EPC Group delivers runs under the EPC Group Lifecycle — Assess, Modernize, Govern, Operate, Enable — so the same senior architects move with the platform from roadmap through year-two managed operations. One contract. One escalation path. One named owner for the data platform.
No. As of June 2026, Microsoft has not announced an end-of-life date for Azure Synapse Analytics. Dedicated SQL pools, serverless SQL pools, Spark pools, and Synapse Pipelines remain in operational support and continue to receive security patching. However, Microsoft has made clear in public roadmap communications that new investment is concentrated on Microsoft Fabric. Net-new Microsoft data platform features — Direct Lake to Power BI, OneLake mirroring, Copilot in Fabric, AI Skills, Data Activator, and Fabric Native Execution Engine — are Fabric-only and are not being backported to Synapse. The practical reading for 2026: Synapse is a mature, supported platform for existing workloads, but Fabric is the strategic data platform for net-new investment. EPC Group typically recommends an honest Synapse Health Check to decide whether to optimize the existing Synapse estate for another 18–36 months or to migrate to Fabric now.
How does Synapse pricing compare to Microsoft Fabric pricing?
They are fundamentally different cost models. Synapse charges component-by-component: Dedicated SQL pool by Data Warehouse Unit (DWU) per hour, serverless SQL pool by terabyte scanned, Spark pool by vCore-hour, pipelines by activity run plus integration runtime hour, and ADLS Gen2 storage separately. Microsoft Fabric charges a single Fabric capacity (F2 → F2048) that covers all compute — Lakehouse, Warehouse, Spark, Data Factory, Real-Time Intelligence, Power BI Premium, and AI Skills — measured against capacity units (CUs) with smoothing and bursting. For organizations already paying for Power BI Premium plus Synapse plus Azure ML, Fabric capacity often delivers cost parity or improvement once consolidated. For organizations running a tightly-tuned dedicated SQL pool at high concurrency with no other Microsoft data platform spend, Fabric capacity can be more expensive at sustained load. The honest answer requires a Fabric Unit of Capacity (FUC) sizing exercise against your actual workload — typically a one-week piece of work inside our Synapse Health Check.
Should we use Azure Synapse or Databricks for our Microsoft-anchored enterprise?
For most Microsoft-anchored enterprises — organizations already running Microsoft 365, Power BI Premium, Azure landing zones, Microsoft Entra identity, and Microsoft Purview governance — Synapse or Microsoft Fabric is the lower-TCO answer because identity, governance, and BI consumption costs are amortized across the existing estate. Databricks delivers stronger pure compute efficiency for heavy Spark workloads (Photon engine), the most mature lakehouse governance (Unity Catalog), and an industry-leading MLOps and AI platform (MLflow, Feature Store, Mosaic AI). The honest 2026 read: choose Databricks when ML platform depth, Delta Live Tables, or Unity Catalog maturity are the primary decision drivers. Choose Synapse or Fabric when Microsoft-native identity, Purview governance, and Power BI Direct Lake matter more. Many Fortune 500 organizations run both — Databricks for heavy ML and Spark workloads, Fabric for Power BI consumption and Microsoft 365 integration — connected through Fabric mirroring to Databricks Unity Catalog.
When does Power BI Direct Lake beat a Synapse Dedicated SQL Pool?
Direct Lake wins when Power BI is the primary consumption surface, when refresh latency or DirectQuery query-time pressure is hurting user experience, and when you have a meaningful number of reports that today require Import-mode refresh cycles or heavy DirectQuery aggregation maintenance. Direct Lake reads V-Order Parquet from OneLake directly into the Power BI VertiPaq engine — you get Import-mode performance with zero refresh, governed by Fabric capacity. The Dedicated SQL Pool still wins when concurrency is extreme (4,000+ concurrent active analytical queries), when star-schema modeling on the warehouse side is already mature and tuned, when your Power BI consumption pattern is heavily DirectQuery with aggregations, or when the FUC sizing exercise shows your concurrency curve would require an F512+ Fabric capacity to match DW7500c performance. We always run the sizing exercise before recommending the cutover.
How do we migrate Synapse Pipelines to Fabric Data Factory?
Synapse Pipelines and Fabric Data Factory share the same underlying runtime — the Azure Data Factory engine — which means pipeline asset migration is one of the lowest-friction parts of a Synapse → Fabric migration. Linked services, datasets, integration runtimes, and pipeline activity definitions are largely portable. Microsoft provides a Synapse-to-Fabric pipeline migration tool inside the Fabric workspace, but EPC Group typically runs a structured five-step process: (1) inventory all pipelines with dependency mapping, (2) classify pipelines by integration runtime type — Azure IR migrates cleanly, Self-Hosted IR requires a new Fabric on-premises data gateway, SSIS IR requires a stay-on-Azure decision, (3) move linked services into Fabric workspace-scoped connections, (4) migrate pipelines in waves with parallel-run validation, (5) decommission Synapse pipelines after a 30-day parallel observation window. Plan two to four weeks for a 50-pipeline portfolio, three to four months for a 500+ pipeline portfolio with hybrid integration runtimes.
How do we migrate Synapse Spark workloads to Fabric Spark?
Synapse Spark runs on Spark 3.4 / Delta 2.4. Fabric Runtime 1.3 runs Spark 3.5 / Delta 3.2 with the Fabric Native Execution Engine. The migration is not lift-and-shift — it is a refactor. Key considerations: (1) Spark API breaking changes between 3.4 and 3.5 affect a small percentage of code, mostly around legacy Pandas-on-Spark APIs and certain UDF signatures, (2) Delta 3.2 introduces deletion vectors and column mapping enhancements that may require table-format migration, (3) custom Scala / Java JARs need rebuilding against Fabric Runtime targets, (4) Spark configuration tuning is different — Fabric capacity smoothing changes how you size pool autoscale. EPC Group migration pattern: containerize each Synapse Spark notebook as a Fabric Notebook with explicit Runtime 1.3 binding, refactor any Pandas-on-Spark calls to the supported 3.5 APIs, rebuild JARs against the Fabric SDK, validate output parity across a 14-day parallel run on a representative workload sample, then cut over by team / domain. A typical 200-notebook portfolio takes 6–10 weeks.
Synapse + Power BI versus Fabric + Power BI — what is the actual difference for analytics consumers?
For end users, the difference shows up in three places. First, refresh and latency: Synapse + Power BI uses Import-mode refresh cycles (typically 1×/day to 6×/hour) or DirectQuery (with query-time latency against the dedicated pool). Fabric + Power BI uses Direct Lake — zero refresh, near-Import performance against OneLake V-Order Parquet. Second, governance: Synapse + Power BI has separate semantic models, separate workspace governance, and separate sensitivity-label flow. Fabric + Power BI shares OneLake and one workspace governance model — sensitivity labels flow from the lakehouse to the semantic model to the report. Third, ad-hoc consumption: Fabric + Power BI users get AI Skills (natural-language Q&A grounded against governed semantic models), Copilot in Power BI, and OneLake integration into Excel and Microsoft 365. None of these are available on Synapse + Power BI. For a Power BI–anchored organization, Fabric is the higher-leverage answer in 2026 — assuming the FUC sizing exercise validates the economics.
Can we run Azure Synapse for federal, HIPAA, or other regulated workloads?
Yes. Azure Synapse Analytics is available in Azure Commercial, Azure Government, and selected sovereign Microsoft Cloud regions, with documented compliance attestations including FedRAMP High, HIPAA / HITRUST eligibility, SOC 2 Type II, PCI DSS, ISO 27001 / 27017 / 27018, and CMMC 2.0–relevant control mapping when deployed under the appropriate Azure Government environment. EPC Group has delivered Synapse for healthcare systems under HIPAA, federal contractors under FedRAMP High and CMMC 2.0 Level 2, financial-services customers under SOC 2 and FINRA, and life-sciences customers under GxP / FDA 21 CFR Part 11. The governance baseline — Microsoft Purview sensitivity labels, Entra conditional access, Defender for Cloud, customer-managed keys with Azure Key Vault, private endpoints — is the same across Synapse and Fabric, so a regulated workload migration to Fabric retains the same compliance posture once Fabric reaches feature parity in your target region. As of June 2026, Fabric is GA in Azure Commercial with expanding Azure Government availability; verify regional and feature parity before committing a regulated workload migration.
A 60-minute call with a senior architect — not a sales lead. We will give you an honest read on whether to optimize your Synapse estate or migrate to Microsoft Fabric, the realistic 12-month cost trajectory either way, and which Synapse → Fabric migration triggers actually apply to your workload. If neither Synapse nor Fabric is the right fit, we will say so on the call and point you to the right platform.