Fabric Warehouse (Polaris and T-SQL), Lakehouse (Spark and Delta Parquet), OneLake shortcuts, Direct Lake, Mirroring, and the consolidated EDW migration — delivered by a Microsoft Solutions Partner founded in 1997.
Microsoft Fabric Warehouse + Lakehouse are the two analytical storage workloads in Fabric. Warehouse runs on the Polaris distributed SQL engine with full T-SQL semantics and ACID transactions. Lakehouse runs on managed Apache Spark with Delta Parquet open table format. Both land in OneLake. Most enterprises use a hybrid medallion — Lakehouse for bronze and silver, Warehouse for gold dimensional models. OneLake shortcuts, Direct Lake mode for Power BI, and Mirroring from Cosmos DB / Azure SQL / Snowflake / PostgreSQL eliminate copy patterns. EPC Group delivers a fixed-fee five-phase Accelerator covering assess, architecture, migrate, modernize, and operate.
The single most important architecture decision in a Fabric data platform engagement is which workload owns which layer. The matrix below is the same one EPC Group walks through in a Phase 1 assessment, dimension by dimension. The honest answer for most enterprises is "both, in a medallion pattern" — but the per-domain classification still drives capacity sizing, skill staffing, and migration sequencing.
Polaris distributed SQL engine plus a serverless T-SQL endpoint — the same engine family that powered Synapse Dedicated SQL Pool, evolved and rebuilt on OneLake.
Apache Spark — Fabric ships managed Spark pools with autoscale and the Fabric Runtime, which is a vendor-curated Spark distribution with Delta, Iceberg, Hudi, and Python data tooling pre-installed.
T-SQL — full DDL, full DML (INSERT, UPDATE, DELETE, MERGE), stored procedures, views, table-valued functions, and SQL Server-style permissions.
Spark SQL, PySpark, Scala, and R against Delta tables — plus a read-only T-SQL endpoint (SQL analytics endpoint) for BI tools that need T-SQL semantics.
Full ACID transactional writes — multi-statement transactions, MERGE semantics, and read-committed snapshot isolation that operational developers expect from SQL Server and Azure SQL.
ACID at the Delta table level via the Delta transaction log — atomic per-table writes, schema enforcement, and time travel — but no multi-table cross-statement transactions in the SQL Server sense.
Open Delta Parquet in OneLake — Fabric Warehouse writes Delta tables that any Lakehouse, Spark notebook, or external engine can read without copying. The change from Synapse Dedicated SQL Pool is that storage is open, not proprietary.
Delta Parquet in OneLake — same physical format as Warehouse, same OneLake mirror, same downstream read path. The two workloads land in the same lake.
Curated enterprise data warehouse, dimensional modeling, T-SQL-fluent BI teams, MERGE-driven SCD Type 2 patterns, financial close, and any workload migrating from Teradata, Synapse Dedicated SQL Pool, Netezza, or Oracle Exadata.
Big data engineering, ML feature stores, semi-structured and unstructured data, Spark-heavy teams, medallion bronze and silver layers, raw zone curation, and any workload migrating from Databricks or Hadoop.
SQL Server and Azure SQL DBA and BI developer skills transfer one-for-one. Most enterprise BI teams reach productivity in days, not weeks.
Spark, Python, and Delta Lake knowledge required for write-side authoring. Read-side BI consumers can use the T-SQL endpoint with no Spark exposure.
Capacity units consumed by query and ingest — same Fabric F-SKU pool as every other workload. No per-table or per-DTU meter.
Capacity units consumed by Spark execution and notebook runtime — autoscale and idle timeout are the primary tuning levers alongside the underlying capacity SKU.
Six patterns cover the overwhelming majority of enterprise Fabric data platform builds. Most customers run two or three in combination — EDW consolidation plus hybrid medallion for finance and supply chain, Mirroring plus Delta sharing for line-of-business federation, big-data engineering plus dimensional modeling for the data science to BI handoff.
The most common Fabric Warehouse engagement pattern is a consolidated enterprise data warehouse replacing a legacy appliance — Teradata, Synapse Dedicated SQL Pool, Netezza, Oracle Exadata, or first-generation Azure SQL DW. The wins are the open Delta Parquet storage in OneLake (no more proprietary block format), the elastic Fabric capacity model (no more cluster sizing or DWU upgrades during quarter-end close), and unified governance with Lakehouse, Power BI, Real-Time Intelligence, and Data Factory in the same tenant. EPC Group has shipped this pattern across financial services, healthcare payers, federal agencies (commercial Fabric, not the Government Community Cloud sovereign tiers — those engagements require Fabric for US Government availability confirmation per use case), and Fortune 500 manufacturers.
When the workload starts as raw event logs, IoT telemetry, clickstream, or unstructured documents — and the downstream consumption is Spark-based feature engineering for ML, plus curated downstream warehouse layers — Fabric Lakehouse is the right landing zone. Spark notebooks own bronze and silver layers. Data Wrangler accelerates exploratory profiling. The MLflow-compatible model registry sits inside the Fabric workspace. Direct Lake mode lets Power BI report directly against the curated Lakehouse gold layer without import or DirectQuery overhead. Companion guidance at /microsoft-fabric-data-engineering-enterprise-guide-2026.
The most resilient enterprise pattern combines both workloads. Raw landing and stream curation happen in Lakehouse — Spark notebooks parse, clean, and normalize semi-structured sources into silver Delta tables. The conformed silver layer mirrors into OneLake (no copy). Fabric Warehouse owns the gold dimensional model with T-SQL MERGE statements driving SCD Type 2, snapshot fact tables, and aggregate fact tables that BI teams and finance close processes depend on. The Warehouse layer is where dimensional governance, T-SQL skill reuse, and audit-grade BI semantics live; the Lakehouse layer is where data engineers and data scientists live.
Kimball dimensional modeling is still the right BI presentation pattern for finance, sales, supply chain, and HR analytics — and Fabric Warehouse is purpose-built for it. T-SQL MERGE drives SCD Type 1 and Type 2 dimensions. Snapshot and accumulating fact tables build inside multi-statement transactions. Aggregate fact tables materialize via stored procedures. Power BI semantic models sit in Direct Lake mode against the gold Warehouse layer for sub-second slicing without import refresh windows. EPC Group ships the EPC Group Kimball Pattern Library — DDL, MERGE templates, audit columns, and SCD scaffolding ready to use day one. See companion /power-bi-data-modeling-best-practices.
Fabric ships a Delta-sharing-compatible cross-workspace data sharing model. A Warehouse or Lakehouse table in one Fabric workspace becomes a shortcut target in another workspace, another tenant, or an external Delta-sharing client (including Databricks Unity Catalog and any Delta Sharing protocol consumer). The shared table is read in place — zero copy, zero ingestion latency, and Entra ID controls the access path. This is the pattern for line-of-business federation, M&A tenant pre-merger data exchange, and partner-side analytics where data residency and sovereignty rule out copy patterns. The shortcut is the unit of sharing, not the table copy.
Fabric Mirroring is a near-real-time, no-code change feed from operational sources into OneLake Delta. Supported sources include Azure Cosmos DB, Azure SQL Database, Azure SQL Managed Instance, on-premises SQL Server via Azure Arc, PostgreSQL, and Snowflake. The mirrored copy is queryable from Warehouse and Lakehouse without ETL, without CDC pipelines, and without ingress meters from the source — Microsoft absorbs the change-feed cost on supported tiers. The pattern unlocks operational analytics against transactional systems without standing up SSIS, ADF copy jobs, or third-party CDC tools. SSIS-to-Data-Factory migration guidance lives at /ssis-to-fabric-data-factory-migration-guide-2026.
Warehouse and Lakehouse share storage but run on entirely different compute engines. Understanding which engine fires for which workload is the difference between a predictable capacity bill and a six-figure surprise.
Fabric Warehouse runs on the Polaris engine — a distributed, vectorized SQL engine family that descends from the Synapse Dedicated SQL Pool lineage but is rebuilt against open Delta Parquet on OneLake. Polaris handles query planning, parallelization across compute nodes, and the storage layer indirection so T-SQL queries operate over Delta tables as if they were native SQL Server objects.
The serverless T-SQL endpoint exposes the Warehouse to any T-SQL client — SQL Server Management Studio, Azure Data Studio, ODBC, JDBC, ADO.NET, Power BI, and the Fabric SQL endpoint URL. There is no DTU or DWU sizing operation. Capacity scales against the F-SKU. The same engine runs the read-only T-SQL analytics endpoint over a Lakehouse, which is what lets BI tools query Lakehouse Delta tables without any Spark exposure.
Fabric Lakehouse runs on managed Apache Spark pools — vendor-managed clusters with autoscale, idle timeout, and the Fabric Runtime preinstalled (a curated Spark distribution that ships with Delta Lake, Iceberg and Hudi readers, MLflow, common Python data libraries, and Microsoft connectors). Spark pools spin up on workload, scale to match concurrent notebook and job execution, and stop on idle to release capacity.
Authoring happens in Fabric notebooks (PySpark, Spark SQL, Scala, R) or Spark job definitions. Output writes to Delta tables in the Lakehouse, which become immediately queryable from the Warehouse via shortcut and from Power BI via Direct Lake. Data Wrangler accelerates exploratory profiling. The MLflow-compatible model registry sits inside the Fabric workspace. See companion guidance at /microsoft-fabric-data-engineering-enterprise-guide-2026.
OneLake is the single, tenant-wide data lake under every Fabric workspace. Every Warehouse table, every Lakehouse Delta table, every KQL Database mirror, and every mirrored operational source lands in OneLake in open Delta Parquet. Three primitives make OneLake the integration fabric instead of yet another lake.
A shortcut is a virtual reference to data held elsewhere — another Fabric workspace, another tenant via Delta Sharing, an Azure Data Lake Storage Gen2 account, an S3 bucket, a Google Cloud Storage bucket, or a Dataverse table. Shortcuts mount into a Lakehouse or Warehouse and query in place. Zero copy, zero duplicate storage, source permissions still apply.
A Lakehouse Spark notebook reads a Warehouse Delta table without copy. A Warehouse T-SQL query reads a Lakehouse Delta table via shortcut. A KQL Database queryset reads either. A Power BI Direct Lake model reads any of them. The integration tax that used to live between operational store, lake, warehouse, and BI semantic model collapses to a permission grant.
A no-code, near-real-time change feed from supported operational sources — Cosmos DB, Azure SQL Database, Azure SQL Managed Instance, on-prem SQL Server via Azure Arc, PostgreSQL, and Snowflake — into OneLake Delta. Microsoft absorbs the source meter on supported tiers. The mirrored copy is immediately queryable from Warehouse and Lakehouse without any CDC infrastructure.
Direct Lake is the Power BI storage mode purpose-built for Fabric. The semantic model loads columns into memory on demand — page by page, directly from the Delta Parquet file in OneLake — without import refresh and without DirectQuery query-time translation. The performance profile is close to import mode for the query shapes the model actually touches, with no refresh window and no DirectQuery latency.
Curated Warehouse or Lakehouse gold layer feeding a semantic model, predictable query shapes, and a consumption audience that needs near-real-time data without scheduled refresh — finance dashboards reading the close-of-day fact table, operational scorecards reading the operational mart, executive dashboards reading the conformed dimension layer.
Very high-cardinality semantic models, heavy calculation group usage, complex aggregations across many disconnected tables, and any pattern that benefits from VertiPaq compression and import-mode hot caching beyond what Direct Lake on-demand paging provides.
Row-level security or sovereignty rules demand the filter executes against the source at query time, or the source is not in OneLake at all. DirectQuery against a mirrored source is one option; DirectQuery against an external system is the other.
Direct Lake models fall back to DirectQuery semantics if the model exceeds the Direct Lake capacity threshold for the F-SKU. Phase 4 modernization includes the fallback monitoring and SKU-right-sizing exercise that prevents production surprise.
The honest cost comparison turns on three levers — the underlying capacity SKU, the reservation strategy, and how aggressively the workload mix shares the capacity. The framework below is what EPC Group walks finance leadership through during the Phase 1 assessment.
Warehouse query, Lakehouse Spark, Power BI semantic refresh, Data Factory pipelines, and every other workload share one F-SKU. Capacity smoothing across workloads is the single largest cost win — most enterprises right-size to a smaller SKU than the sum-of-parts forecast for the same workloads on Dedicated SQL Pool, Power BI Premium, and ADF would have predicted.
One-year Reserved Capacity discounts 41 percent against Pay-As-You-Go. The Reservation move is the single largest commercial lever once daily utilization is predictable for sixty days. EPC Group includes the Reserved Capacity timing recommendation in Phase 5.
Dedicated SQL Pool DWU sizing was rigid — scaling required cluster pause-resume and blocked active queries. Fabric capacity scales elastically. The same workload on Fabric typically lands twelve to twenty-eight percent below the DWU-equivalent spend because off-hours capacity smoothing across non-Warehouse workloads recovers idle cost.
Snowflake bills credits per warehouse second with auto-suspend. For Microsoft-anchored enterprises the apples-to-apples comparison depends on concurrency, idle pattern, and whether Power BI Premium and ADF spend get folded into the same capacity. The unified Fabric meter is usually the deciding factor for tenants already heavy on Microsoft.
OneLake storage bills at object-storage rates separately from capacity. For most workloads OneLake storage is a small fraction of total cost. High-retention, high-cardinality tables are worth sizing explicitly in Phase 1.
Mirroring is free on the source side for Microsoft-native operational stores on supported tiers (Cosmos DB, Azure SQL on certain SKUs). Microsoft absorbs the change-feed cost. The mirrored copy lives in OneLake at standard storage rate. The pattern removes most of the CDC tooling line item.
The accelerator anchors on The EPC Group Lifecycle — Assess, Architecture, Migrate, Modernize, Operate. Fixed-scope between $200,000 and $800,000 depending on source system count, workload complexity, regulatory scope, and managed-service tail. Senior architect-led, named on-record, no offshore handoff.
Phase one inventories every existing data warehouse, mart, lake, and reporting layer in scope — Teradata, Synapse Dedicated SQL Pool, Netezza, Oracle Exadata, on-premises SQL Server, Snowflake, Databricks, Redshift — classifies each workload as Warehouse-bound, Lakehouse-bound, or hybrid medallion, models Fabric capacity unit consumption against current and projected workload, and ships a fixed-fee, costed roadmap for Phases 2 through 5. Output is the package a steering committee uses to approve the migration.
Phase two establishes the durable Fabric Warehouse and Lakehouse architecture — workspace topology (production, non-production, sandbox, line-of-business federation), Entra ID security model (workspace roles, item permissions, row-level security, column-level security, dynamic data masking), OneLake shortcut topology, mirroring source decisions, Direct Lake mode policies for Power BI, and the deployment pipeline model (Git integration, Fabric deployment pipelines, environment promotion).
Phase three migrates source warehouses and lakes in waves. Wave one is highest-value, lowest-complexity — a finance mart or a sales cube where the dimensional model is well-understood. Wave two extends to operational warehouses. Wave three covers the long tail. Each wave runs parallel against the legacy system for two close cycles before cutover, with row-count, hash, and grain-level reconciliation reporting that auditors and finance leadership accept. EPC Group ships the migration tooling — schema converters, MERGE generators, parallel-run reconciliation harness, and cutover runbooks.
Phase four upgrades the post-migration landscape with Fabric-native capabilities — Power BI Direct Lake mode against gold Warehouse and Lakehouse tables (no import refresh windows, no DirectQuery latency), Mirroring from operational sources (Cosmos DB, Azure SQL, Snowflake, PostgreSQL) so operational analytics flow without CDC pipelines, Spark-based ML feature engineering inside the Lakehouse, and Real-Time Intelligence wiring for streaming sources. The wave-based modernization is what converts a lift-and-shift into a strategic platform.
Phase five operationalizes the platform — DBA and BI run-books, FinOps tuning (capacity utilization profile, Spark autoscale policy, idle timeout, hot-cache policy), the Reserved Capacity move once daily utilization is predictable for sixty days, governance review cadence, and either handoff to internal operations or to EPC Group managed Fabric services for steady-state run. Senior architect stays named on-record through the first thirty days of steady-state production.
Fabric Warehouse and Lakehouse inherit the broader Fabric and Microsoft Cloud compliance footprint — HIPAA Business Associate Agreement coverage, SOC 2 Type II, FedRAMP High for Azure Government deployments (Fabric for US Government regional availability confirmed per workload), FINRA-aligned controls for financial services, CMMC 2.0 for defense contractors, and GxP for life sciences. EPC Group extends the Microsoft control mapping into an auditor-ready matrix tying every Warehouse schema, Lakehouse table, shortcut, Mirroring source, RLS policy, and CLS rule to the regulatory control identifiers in scope. See our standards alignment library for the full mapping.
Microsoft Solutions Partner with the Data & AI designation plus five additional designations covering Modern Work, Infrastructure, Security, Digital & App Innovation, and Business Applications. Senior architects average two decades of Microsoft platform delivery experience across Power BI, SQL Server, Synapse, and Fabric.
Founder Errin O’Connor has nearly three decades of Microsoft consulting leadership and is a four-time author for Microsoft Press and Sams across Power BI and SharePoint — the Power BI book remains a working reference for enterprise dimensional modeling and semantic model design on Fabric Warehouse.
Every Fabric Warehouse + Lakehouse engagement is fixed-fee with a costed roadmap and a named senior architect on-record from kickoff through go-live. The parallel-run reconciliation harness is what gives finance and audit teams the confidence to sign off on EDW cutover. No T&M overruns, no offshore handoff, no junior-led production cutover.
EPC Group ships Warehouse schemas, Lakehouse Delta scaffolding, RLS policies, CLS rules, Purview classification labels, and governance matrices mapped to HIPAA, SOC 2, FedRAMP, FINRA, CMMC, and GxP — the evidence auditors actually accept, not generic platform screenshots.
Fabric Warehouse runs on the Polaris distributed SQL engine and exposes a full T-SQL surface — DDL, DML (INSERT, UPDATE, DELETE, MERGE), stored procedures, views, multi-statement transactions, and SQL Server-style permissions. Fabric Lakehouse runs on managed Apache Spark with a read-only T-SQL analytics endpoint over the same Delta tables. Both write open Delta Parquet to OneLake, so a Warehouse table is queryable from a Lakehouse notebook and a Lakehouse Delta table is queryable from Warehouse via shortcut — no copy. The decision is which authoring surface fits the workload: T-SQL teams and dimensional modeling go Warehouse, Spark teams and big-data engineering go Lakehouse, most enterprises use a hybrid medallion (Lakehouse bronze and silver, Warehouse gold).
Fabric Warehouse is the strategic successor to Synapse Dedicated SQL Pool. Same Polaris engine family, evolved. Three concrete differences. First, storage is open Delta Parquet in OneLake, not the proprietary block format of Dedicated SQL Pool — every other engine can read it without copy. Second, capacity is elastic Fabric F-SKU consumption, not DWU sizing — no manual scale operations during quarter-end close. Third, governance, security, and BI integration sit inside the unified Fabric workspace model rather than Synapse Studio. New builds default to Fabric Warehouse. Existing Synapse Dedicated SQL Pool customers migrate via the EPC Group five-phase Accelerator — see also /azure-synapse-analytics-enterprise-guide-2026.
For Microsoft-anchored enterprises already invested in Power BI, Microsoft 365, Entra ID, Purview, and the broader Fabric workload set, Fabric Warehouse plus Lakehouse wins on unified governance (one Entra ID model, one Purview catalog, one capacity meter), open OneLake storage (Delta Parquet readable by every external engine), zero-copy Direct Lake mode for Power BI, free Microsoft-native source mirroring (Cosmos DB, Azure SQL, on-prem SQL Server via Arc), and lower commercial complexity inside an existing Microsoft EA or MCA. Snowflake wins on multi-cloud portability and a deeper third-party data marketplace. Databricks wins on Spark notebook tooling depth and ML platform maturity. The honest decision turns on incumbent investment, multi-cloud requirement, and where the analytics consumption audience already lives.
Fabric Warehouse supports the majority of the production T-SQL surface — DDL (CREATE / ALTER / DROP for tables, views, schemas, procedures, functions), DML (INSERT, UPDATE, DELETE, MERGE), multi-statement transactions, stored procedures, table-valued functions, common table expressions, window functions, and SQL Server-style permissions via Entra ID. Notable gaps versus SQL Server engine — identity columns behave differently, some legacy index types are not present, cross-database queries follow the Fabric workspace and shortcut model rather than three-part naming, and a handful of legacy SET options are not supported. The migration assessment in Phase 1 catalogs every incompatibility and ships a remediation pattern per source workload.
Mirroring is the right answer when the source is a supported system (Cosmos DB, Azure SQL Database, Azure SQL Managed Instance, on-premises SQL Server via Azure Arc, PostgreSQL, Snowflake) and the requirement is near-real-time replication into OneLake Delta with no transformation. It is no-code, zero-meter on the source side for Microsoft-native sources, and removes CDC infrastructure. Data Factory pipelines (and the SSIS-to-ADF migration path at /ssis-to-fabric-data-factory-migration-guide-2026) are the right answer when transformation is required during transit, when the source is not a Mirroring target, or when the pattern is batch ETL with scheduling, parameterization, and lineage. Many enterprise builds use both — Mirroring for the supported operational sources, Data Factory for the long tail.
A OneLake shortcut is a virtual reference to data held elsewhere — another Fabric workspace, another tenant, an Azure Data Lake Storage Gen2 account, an S3 bucket, a Google Cloud Storage bucket, a Dataverse table, or a Delta Sharing endpoint. Shortcuts are mounted into a Lakehouse or Warehouse and queried in place — no copy, no ingestion latency, no duplicate storage cost. Permissions on the underlying source still apply. The pattern unlocks line-of-business federation, M&A pre-merger data exchange, multi-cloud Delta sharing, and the hybrid medallion architecture where bronze and silver live in Lakehouse and gold in Warehouse reads from the silver shortcut. Shortcuts are the architectural unit that makes OneLake the lake, not a copy of every other lake.
Direct Lake mode is a Power BI storage mode that reads Delta Parquet directly from OneLake without import refresh and without DirectQuery query-time translation. The semantic model loads columns into memory on-demand, page by page, from the Delta file. Performance is import-like for the queries the model touches, with no refresh window and no DirectQuery latency. Direct Lake is the right mode when the underlying Warehouse or Lakehouse gold layer is curated for BI consumption, when query patterns are reasonably predictable, and when the audience needs near-real-time data without scheduled refresh. Import mode still wins for very high-cardinality models with heavy calculation groups; DirectQuery still wins when row-level security demands query-time filtering against an external source. EPC Group ships the decision matrix as part of Phase 4 modernization.
A fixed-fee five-phase Accelerator anchored on the EPC Group Lifecycle — Assess, Architecture, Migrate, Modernize, Operate — priced $200K to $800K depending on source-system count, workload complexity, regulatory scope, and managed-service tail. Deliverables include the costed roadmap with capacity sizing, Entra ID security model with RLS / CLS / DDM, workspace topology with Git integration and deployment pipelines, EPC Group Kimball Pattern Library DDL and MERGE templates, parallel-run reconciliation harness for finance-grade cutover, Direct Lake activation, Mirroring source onboarding, Spark feature engineering scaffolding, FinOps tuning, Reserved Capacity move, and an auditor-ready control matrix. Senior architect-led, named on-record, no offshore handoff.
Fabric Warehouse and Lakehouse sit inside the broader Fabric data platform and Microsoft Cloud orchestration story. These hubs cover adjacent and complementary territory.
The end-to-end Microsoft cloud orchestration model under which Fabric Warehouse and Lakehouse sit as the analytical storage plane.
Service overview for Fabric advisory, implementation, modernization, and managed services across Warehouse, Lakehouse, Real-Time Intelligence, and Power BI.
The pillar hub for Microsoft Fabric — workspace topology, capacity sizing, FinOps, governance, and the workload mix that Warehouse and Lakehouse anchor.
Synapse architecture and the migration trajectory from Synapse Dedicated SQL Pool and Synapse Spark Pool into Fabric Warehouse and Lakehouse.
The companion real-time analytics workload — Eventhouse and KQL Database that mirror to the same OneLake the Warehouse and Lakehouse share.
The decision framework for choosing operational database, data warehouse, data lake, lakehouse, or KQL Database — and how Fabric Warehouse + Lakehouse fit.
The companion ETL modernization guide — migrating SSIS packages to Fabric Data Factory pipelines feeding Warehouse and Lakehouse landing zones.
The data engineering deep dive — Spark, Delta, notebook patterns, and the Lakehouse-side authoring story that complements the Warehouse-side dimensional layer.
Book a Fabric data platform briefing with an EPC Group senior architect. Two-hour working session — workload classification, source inventory, capacity sizing, accelerator scoping. Zero obligation, board-ready output.
AI assistant — not human