Microsoft Fabric is the consolidation play: data engineering, warehousing, real time analytics, data science, and Power BI in one SaaS platform on one storage layer with one billing meter. After yesterday’s Synapse deep dive, today is about what changes with Fabric and the decisions that matter when adopting it.

OneLake and the End of Copy Culture

OneLake is a single logical data lake for the whole tenant, built on ADLS Gen2, with everything stored as Delta Parquet. The architectural weight sits on two features. First, every Fabric engine reads and writes the same open format in the same lake, so the warehouse, the Spark notebooks, and Power BI are views over one copy of the data rather than three synchronized copies. Second, shortcuts mount external data, ADLS Gen2 accounts, S3 buckets, Dataverse, into OneLake without moving it, which means your existing lake from the storage post participates in Fabric on day one, no migration project required. The cultural shift is bigger than the technical one: teams accustomed to extracting their own copies have to learn that the copy is already there and already governed.

Lakehouse or Warehouse

Fabric offers both a lakehouse (files plus Delta tables, Spark first, SQL endpoint read only over the tables) and a warehouse (full T-SQL surface including multi table transactions, SQL first). The decision is about your team and your write patterns, not fashion: data engineering teams living in notebooks and Spark, with medallion style bronze to silver to gold pipelines, want the lakehouse; SQL centric teams porting warehouse workloads with stored procedure logic and fine grained T-SQL DML want the warehouse. They interoperate through OneLake anyway, gold layer tables in a lakehouse are queryable from the warehouse and vice versa, so the medallion pattern commonly lands as lakehouse for bronze and silver, either for gold. Do not agonize; the data is portable between them because it is all Delta underneath.

Direct Lake: The Power BI Payoff

The historical Power BI tradeoff was import mode (fast, but scheduled refreshes and dataset copies) versus DirectQuery (current, but every visual is a database query). Direct Lake mode reads Delta files from OneLake straight into the Analysis Services engine: import grade performance with lake currency and no refresh pipeline. It is the single most compelling reason to land curated data in OneLake, and it rewards the same hygiene as every columnar system, well sized Parquet row groups, V-Order optimized writes (Fabric’s default), and dimensional models rather than one giant wide table. Watch the fallback behavior: models exceeding capacity limits or using unsupported features fall back to DirectQuery silently, and the performance cliff will page someone, so monitor for it.

Capacity: One Meter to Watch

Everything runs on capacity units (F SKUs), one pool of compute shared by all workloads in the capacities you assign. The smoothing model averages usage over time windows, bursts borrow against quiet periods, and sustained over consumption throttles interactive queries first, then background jobs, which in practice means one team’s runaway notebook can slow another team’s dashboards. Treat capacity like the shared resource it is: separate capacities for production BI and heavy data engineering if the budget allows, the capacity metrics app reviewed weekly, alerts on throttling, and surge protection configured. Start smaller than you think with pay as you go, measure a real month, then reserve. And bring the governance stack from this series with you: workspaces mapped to domains, sensitivity labels, and the purview integration for lineage, because a platform that makes data this easy to share makes ungoverned sharing exactly as easy.

Cheers
Osama