TL;DR
A Microsoft Fabric Lakehouse stores structured and unstructured data together in OneLake. It keeps two areas, Tables for managed Delta tables and Files for everything else. Spark notebooks read and write it. Fabric also creates a SQL endpoint, so analysts can query the same tables with read-only T-SQL. Choose a Lakehouse when your team builds with Spark or works with mixed data types. Choose a Fabric Warehouse when your team builds with T-SQL and needs multi-table transactions.
Key Takeaways A Fabric Lakehouse stores everything in OneLake as open Delta tables, so Spark, T-SQL, KQL and Power BI all read one copy without moving data between systems. Only Delta tables appear in the SQL analytics endpoint. A Parquet or CSV file dropped into the Tables area stays invisible to every T-SQL and Power BI consumer until it is converted. Schemas are switched on by default when you create a Lakehouse in the Fabric portal and switched off by default through the REST API, and Microsoft still ships no migration tool for a Lakehouse created before schemas existed. Six documented ingestion paths exist. File upload, shortcuts, Dataflow Gen2, data pipelines, notebook code and Eventstream each suit a different source, volume and skill set. Lakehouse and Warehouse share the same SQL engine and the same Delta storage in OneLake. Development style, multi-table transactions and data type decide which one you pick. Microsoft recommends medallion layering with each bronze, silver and gold layer in its own workspace, and Liquid Clustering rather than partitioning for the silver and gold layers. Runtime 2.0 with Apache Spark 4.1 and Delta Lake 4.2 is now the generally available production runtime, while new workspaces still default to the older Runtime 1.3. Watch on YouTube
Microsoft Fabric Migration: Why Enterprises Are Consolidating
Why enterprise teams consolidate onto one Fabric platform, and what the single-copy Lakehouse model changes for them.
Why Most Fabric Lakehouse Projects Stall on Structure, Not Compute Microsoft’s own benchmark for the Fabric Native Execution Engine reports up to six times faster performance than open-source Spark on TPC-DS at scale factor 1000. That works out to roughly 83% compute-cost savings on a fixed-size cluster (Microsoft Learn, Apache Spark runtime in Fabric ). Raw speed is rarely what holds a Lakehouse project up.
What holds it up is structure. A table lands in the wrong area and never reaches Power BI. A Lakehouse gets created without schemas and cannot later take row-level security. Files accumulate at 4 MB each until every query pays a metadata tax.
This guide works through the structure first, then the paths data takes into it. After that come the layering, security and maintenance decisions that decide whether it survives its second year.
What a Microsoft Fabric Lakehouse Actually Is A Lakehouse in Microsoft Fabric is a workspace item that stores structured and unstructured data in one place. It manages that data with Delta Lake and exposes it to both Apache Spark and SQL. Microsoft describes it as combining the scale of a data lake with the querying of a warehouse (Microsoft Learn, What is a lakehouse? ). Nothing moves between the two.
Four things come with it. One copy of data serving both engineering and analytics workloads. Delta Lake format for ACID transactions, schema enforcement and time travel. Spark and SQL access side by side, so engineers stay in notebooks while analysts write T-SQL. Built-in wiring to Power BI, pipelines, dataflows and every other Fabric item.
What It Replaces The pattern a Lakehouse displaces is the two-copy stack. Raw data landed in a lake, a subset was copied into a warehouse for reporting, and the two drifted apart within a quarter. Teams then spent their time reconciling numbers that should never have diverged.
With a Fabric Lakehouse the warehouse-style query runs against the same Delta files the Spark job wrote. There is no copy step and no reconciliation job, which removes a whole class of data quality problems before they start.
Where It Sits in Fabric Fabric groups its capabilities into workloads. The Lakehouse belongs to Fabric Data Engineering , alongside notebooks, Spark job definitions and environments. Its sibling in Data Warehouse is the Warehouse item, and both write to the same OneLake storage layer .
That shared foundation is the part people miss. Choosing between them is not a storage decision, because the storage is identical. It is a decision about tooling and transaction semantics, covered further down this page.
How a Microsoft Fabric Lakehouse Is Put Together Four components make up every Microsoft Fabric Lakehouse. Understanding what each one owns explains most of the behaviour teams find surprising later.
OneLake, the Storage Underneath OneLake is provisioned automatically with every Fabric tenant and acts as the single logical lake for the whole organisation. It is built on Azure Data Lake Storage Gen2 and addressed through a single namespace. A Lakehouse in one workspace and a Warehouse in another end up as two folders in the same lake.
Every Fabric engine writes Delta by default into OneLake. That is what makes cross-engine querying work without an export step.
Delta Lake as the Table Format Delta Lake stores data as Parquet files plus a transaction log. The log is what delivers ACID guarantees, schema enforcement, and the ability to read an earlier version of a table. Fabric’s native writer also applies V-Order optimisation to the Parquet files on write, which speeds up reads across Power BI, SQL and Spark.
Because the log records every write, a Lakehouse table carries its own history. Reading, restoring and expiring those versions is a topic of its own. We cover the mechanics in Microsoft Fabric time travel in a Lakehouse .
The SQL Analytics Endpoint Creating a Lakehouse automatically generates a SQL analytics endpoint. It gives analysts a T-SQL surface over the Lakehouse Delta tables without anyone standing up a separate Warehouse, and it supports views and table-valued functions.
It is read-only. Full DQL works, DML does not, and DDL is limited to objects like views. Treat it as a serving layer for exploration, reporting and ad-hoc queries. Writes belong in Spark or in a Warehouse.
The Lakehouse Explorer and Query Explorer The explorer is the browser interface over the two storage areas. You switch between table view and file view, load data, manage metadata, and attach more than one Lakehouse at a time. The Spark SQL query explorer sits alongside it and runs Spark SQL without leaving the page, with IntelliSense, cross-schema querying and inline charts.
Tables and Files, and Why the Split Decides Everything Later A Microsoft Fabric Lakehouse provisions exactly two top-level folders. Tables holds managed Delta tables. Files holds everything else, in any format, at any size.
What Automatic Table Discovery Does Drop a file into the Tables area and Fabric validates it against the supported formats. It extracts column names, data types, compression and partitioning, then registers the table in the metastore. The table becomes queryable from Spark SQL and T-SQL straight away, with no CREATE TABLE statement written by hand.
The supported format for that automatic registration is Delta. Nothing else.
The Failure Mode Nobody Documents Here is the consequence, and it costs teams a day of debugging on a regular basis. Only Delta tables appear in the SQL analytics endpoint. A Parquet file, a CSV, an ORC file or an Avro file will sit in the Tables area and look perfectly healthy in the explorer. It stays completely absent from every T-SQL query and every Power BI semantic model built on the endpoint.
The symptom reads like a permissions problem or a refresh problem. It is neither. The fix is to convert the file to Delta format, after which it appears immediately.
The 10 GB Metadata Ceiling Lakehouses created without schemas carry a maximum metadata size of 10 GB. Publishing or updating any semantic model that exceeds it fails. The documented remedies are to use a schema-enabled Lakehouse instead, to remove tables and columns, or to split a large model across several Lakehouses.
Teams that inherited a Lakehouse from 2024 and kept adding tables to a flat Tables list are the ones who meet this limit. It is a good reason to care about the next section.
Lakehouse Schemas and the Four-Part Namespace Schemas group Lakehouse tables into named collections such as sales, marketing or hr. They changed from a nice-to-have into a prerequisite once several Fabric features started depending on them (Microsoft Learn, Lakehouse schemas ).
What Schemas Gate Browsing tables by business area instead of one flat list, which matters more with every table you add. Schema-level access control, plus row-level and column-level security on the tables inside a schema. Cross-workspace queries using the four-part namespace workspace.lakehouse.schema.table. Schema shortcuts, which map a schema to a folder in another Lakehouse or in ADLS Gen2 so external Delta tables show up as local tables. Materialized lake views, which require a schema-enabled Lakehouse. The Default Nobody Reads Create a Lakehouse in the Fabric portal and the Lakehouse schemas box is already ticked. Create one through the Create Lakehouse REST API and schemas are off unless you pass "enableSchemas": true in the creation payload.
Teams that provision Fabric items through infrastructure-as-code therefore end up with schema-less Lakehouses by accident while the ones clicking through the portal get schemas for free. Every schema-enabled Lakehouse also gets a dbo default schema that cannot be renamed or removed.
There Is Still No Migration Path Microsoft states plainly that tools to convert a non-schema Lakehouse into a schema-enabled one without moving data or taking downtime are not yet available. Fabric will keep supporting both types, and Spark can join across them in the same query.
The recommended preparation is to start writing four-part names now, using dbo even on a Lakehouse that has no schemas. Spark accepts workspace.lakehouse.dbo.table against a non-schema Lakehouse today, so the code is ready when the conversion path arrives.
Two Live Limitations A schema-enabled Lakehouse cannot currently be shared through workspace-level sharing. The documented workaround is to create shortcuts in a Lakehouse the user already has a workspace role on, and reference the shared tables through those. External table metadata over ADLS Gen2 is also unsupported directly, and again shortcuts are the route.
Six Ways to Get Data Into a Microsoft Fabric Lakehouse Microsoft documents six ingestion paths into a Microsoft Fabric Lakehouse. Picking the wrong one is the most common reason a Fabric project needs rework (Microsoft Learn, Data ingestion options for a lakehouse ). The right one depends on the source, the volume, how much transformation is involved, and whether the load is one-off or continuous.
Kanerika Service
Microsoft Fabric Implementation and Migration
Our data engineering teams design and build Fabric Lakehouses, and move pipelines and semantic models off SSIS, Azure Data Factory, Informatica and Alteryx.
See What We Build →
Method What it does Who runs it Best for Watch out for Upload files Drag a file straight into the Files area Anyone Reference data, one-off samples, prototyping No lineage and no schedule, so it never belongs in production Shortcuts Live reference to data that stays where it is Data engineer Data already in OneLake, ADLS Gen2, S3 or Google storage Read-only, and only Delta folders surface in the SQL endpoint Dataflow Gen2 Low-code visual ingestion and preparation Analyst or citizen developer SaaS sources and modest volumes with light shaping Capacity cost climbs quickly at large volumes Data pipelines Orchestrated copy activity and control flow Data engineer Scheduled enterprise loads from databases and on-premises systems Gateway configuration is usually the long pole for on-premises sources Notebook code Spark reads, transforms and writes Delta directly Data engineer or data scientist Complex transformation, large volumes, custom logic Session startup time makes it a poor fit for tiny frequent loads Eventstream Continuous ingestion of streaming events Data engineer IoT telemetry, change feeds, application events Produces small files fast, so plan compaction from day one
Table 1: The six documented ingestion paths into a Fabric Lakehouse and when each one fits.
Writing Delta From a Notebook The notebook path is the one worth getting right, because it is where most production loading happens. The write that matters is a Delta write.
A Spark DataFrame goes to a managed table with df.write.mode("overwrite").saveAsTable("marketing.productdevelopment"), where marketing is the schema and productdevelopment is the table. Omit the schema name and the table lands in dbo.
Writing a CSV or a Parquet file and then converting it to a table afterwards still works, and plenty of older tutorials teach it. It is a slower route with an extra artefact to clean up, and it gives you none of the Delta guarantees until the conversion completes.
Shortcuts: Querying Data You Never Copied Shortcuts create a live reference to data held somewhere else and make it appear inside the Lakehouse. The data stays in its original location, and changes at the source show up through the shortcut.
Where Shortcuts Can Point Other locations in OneLake, Azure Data Lake Storage Gen2, Amazon S3 and Google storage are all supported targets, and the mechanics are covered in our guide to OneLake shortcuts . Cross-tenant data sharing extends the same idea to governed data held by another organisation.
For teams running cloud data integration across more than one platform, this removes the copy job that used to sit between them. Its schedule, its failures and its storage bill go with it.
Why Bronze Should Usually Be Shortcuts Microsoft’s medallion guidance is explicit on this point. When the source data already sits in OneLake, ADLS Gen2, Amazon S3 or Google storage, create a shortcut in the bronze layer instead of copying the data across.
That single choice removes a duplication of your entire raw estate. It also removes the window in which the copy is stale, which is the window where reconciliation questions get asked.
Querying a Lakehouse With Spark, T-SQL, and KQL A Microsoft Fabric Lakehouse gives you one copy of the data and several engines over it. Which engine a given person uses depends on what they already know.
Notebooks and Spark SQL Notebooks run Python, Scala, Spark SQL and R against Lakehouse tables and folders. The object explorer groups tables by schema, and dragging a table into a cell generates a snippet with the correct schema reference. Using schemas in notebook code requires the notebook’s default Lakehouse to be schema-enabled, or no default Lakehouse to be selected at all.
The four-part namespace makes cross-workspace joins a single statement. A query can join an employees table in an HR Lakehouse to a departments table in a corporate Lakehouse in a different workspace. The running user needs permission on both.
The SQL Analytics Endpoint in Practice Analysts connect to the endpoint and write familiar T-SQL, the same surface our T-SQL notebooks guide covers in depth. Report builders connect Power BI to it. Because it is read-only, neither group can disturb a Spark workload that is running against the same tables.
One change here catches people out. Since 5 September 2025, default semantic models are no longer created automatically when you create a Lakehouse. Existing default models were decoupled from their parent items by 30 November 2025 and became independent semantic models. Anyone following a 2024 tutorial that says “open the default semantic model” will not find one, and needs to create a model explicitly. Getting that model right matters, and the rules are the same as they are for any self-service BI layer.
The Eventhouse Endpoint The Lakehouse ribbon carries an Analyze data with dropdown that opens the same data in a different engine. Alongside the SQL analytics endpoint and a notebook, it offers an Eventhouse endpoint for KQL queries, which suits high-volume time-series and real-time analytics patterns.
Microsoft Fabric Lakehouse vs Fabric Warehouse This is the question the search results are full of and the one every Fabric programme argues about in its first month. Microsoft publishes a decision guide for it, and the guide is refreshingly blunt (Microsoft Learn, Warehouse and Lakehouse decision guide ).
Three Questions That Settle It How does your team want to develop? Apache Spark in Python, Scala, Spark SQL or R points to a Lakehouse. T-SQL points to a Warehouse. Do you need multi-table transactions? Yes points to a Warehouse. No points to a Lakehouse. What kind of data are you analysing? Mixed structured and unstructured, or you are unsure, points to a Lakehouse. Structured only points to a Warehouse. The Full Comparison Criterion Fabric Lakehouse (SQL analytics endpoint) Fabric Warehouse Primary development tool Apache Spark in Python, Scala, SQL or R T-SQL Developer profile Data engineers and SQL developers SQL developers and citizen developers Data types Structured and unstructured Structured Multi-table transactions No Yes, full ACID across tables Delta table support Reads Delta tables Reads and writes Delta tables T-SQL surface Full DQL, no DML, limited DDL such as views and table-valued functions Full DQL, DML and DDL with transaction support Loading methods Spark, pipelines, dataflows, shortcuts T-SQL COPY INTO, INSERT, CREATE TABLE AS SELECT, pipelines, dataflows Storage layer Open Delta format in OneLake Open Delta format in OneLake Best fit Data engineering, data science, medallion architectures, staging and archival zones Enterprise and departmental warehousing, dimensional modelling, BI-first teams
Table 2: Fabric Lakehouse against Fabric Warehouse, drawn from Microsoft’s published decision guide.
You Can Have Both Nothing forces a single choice. A common shape is to land and transform in a Lakehouse with Spark, then expose curated tables to a Warehouse for SQL-based reporting. Cross-database queries run across warehouses and lakehouses with no data duplication, so the two items read each other’s tables directly.
Some teams are still weighing the wider platform question. Our Microsoft Fabric and Databricks comparison and the three-way platform comparison go further than this page can.
Medallion Layering Inside a Microsoft Fabric Lakehouse Medallion is Microsoft’s recommended design approach for Fabric, and a Microsoft Fabric Lakehouse in OneLake is where it gets implemented (Microsoft Learn, Implement medallion lakehouse architecture in Fabric ). Three layers, each one a higher grade of the same data.
What Each Layer Holds Bronze stores everything exactly as it arrives, with no changes allowed. Silver fixes errors, standardises formats and removes duplicates. Gold organises the result for reports and dashboards.
A worked example from Microsoft’s own documentation. Bronze holds raw web sales in JSON, raw warehouse inventory in CSV and a raw CRM customer export. Silver standardises date formats, converts currency to USD, removes test transactions and matches customer records across systems. Gold builds a daily sales table, a customer lifetime value table and an inventory forecasting table.
One Lakehouse Per Layer, One Workspace Per Lakehouse Microsoft names two deployment patterns. In the first, every layer is a Lakehouse and business users read through the SQL analytics endpoint. In the second, bronze and silver are Lakehouses and gold is a Warehouse, with business users reading through the warehouse endpoint.
On placement the guidance is firm. You can put all the lakehouses in one workspace, but Microsoft recommends a separate workspace per lakehouse because it gives better control and governance at the layer level. That is also what makes deployment pipelines between development, test and production behave sensibly.
Materialized Lake Views Rather than hand-building pipelines between layers, materialized lake views let you define the transformations declaratively in SQL. Fabric works out the execution order from the view dependencies and enforces data quality rules as data moves between layers. It also decides whether each view needs an incremental, full or no refresh, and shows lineage across the layers.
They need a schema-enabled Lakehouse, which is the second time on this page that schemas turn out to be the gate.
Keeping Delta Tables Fast in a Fabric Lakehouse A Microsoft Fabric Lakehouse that performs on day one and crawls on day four hundred usually has a file problem. Compute is rarely the cause. Three settings decide most of it.
V-Order Fabric’s native writer applies V-Order optimisation to Delta Parquet files by default. It is a write-time optimisation that makes reads faster across every Fabric engine, including Power BI, SQL and Spark. It costs a little on write and pays back on every read, which is the right trade for gold tables read hundreds of times a day.
File Size Big data engines do better with a few large files than with many small ones, because every metadata and file operation costs the engine time. Microsoft’s target range is 128 MB to 1 GB per file, varying by table size and how the layer is consumed.
The guidance differs by layer. Bronze tolerates smaller files given the raw nature of the data, as long as modification and preparation happen in Spark. Silver wants moderate file sizes to balance write and read performance. Gold wants larger files and larger row groups, because that is where the query volume lands.
Liquid Clustering Replaces Partitioning This one has changed and older material has not caught up. For silver and gold layers Microsoft now recommends Liquid Clustering rather than partitioning. Partitioning remains acceptable in bronze but is discouraged for new implementations.
If you do keep a partitioned target table and run a MERGE to upsert into it, use a partition filter so the engine can skip partitions that need no update.
Layer Storage format File size Data organisation Bronze Original format, or a shortcut to the source Smaller files acceptable Partitioning allowed, discouraged for new builds Silver Delta tables Moderate, balancing read and write Liquid Clustering Gold Delta tables Larger files, larger row groups Liquid Clustering
Table 3: Microsoft’s per-layer guidance for Delta table storage in a Fabric medallion Lakehouse.
Which Runtime You Are Actually On Fabric Runtime 2.0 carries Apache Spark 4.1, Delta Lake 4.2, Python 3.13 and Java 21, and it is the generally available runtime Microsoft tells you to use for production. Runtime 1.3, with Spark 3.5.5 and Delta Lake 3.2, has reached end of standard support.
The catch is that all new workspaces still default to Runtime 1.3. Check Workspace Settings, then Data Engineering and Science, then Spark settings, and move the Environment tab to 2.0 deliberately. Library compatibility is the thing to test first, because JARs frequently break across the Scala, Java and Spark version jump.
Securing a Microsoft Fabric Lakehouse Security in a Microsoft Fabric Lakehouse works at three levels, and the level you can reach depends on a decision made when the item was created.
Workspace Roles First Workspace roles decide who can see the Lakehouse item at all. They are coarse by design and they are the layer most teams stop at, which is how a finance Lakehouse ends up readable by everyone in a shared analytics workspace.
Schema-Level Access Grouping tables into schemas lets you grant different teams access to different schemas within one Lakehouse. An hr schema and a sales schema can live in the same item with different audiences.
Row and Column Security OneLake row-level and column-level security apply to tables inside schemas, which means they need a schema-enabled Lakehouse. A Lakehouse created before schemas existed, or provisioned through the REST API without the flag, cannot take them today and has no supported conversion path.
That is the single strongest argument for enabling schemas at creation time even when you have no immediate use for them. Retrofitting is the expensive option. Teams building a wider Fabric governance model should make this a provisioning standard for every new Lakehouse.
A Worked Example On a recent order-analytics build, Kanerika implemented four-level hierarchical row-level security. It aligned to region, Sales Organization, Sales Office and Sales Group. A regional manager and a global head opened the same report and saw different numbers, with neither of them filtering anything. That hierarchy is only expressible because the security sits on the data rather than on the report.
Free Checklist
Microsoft Fabric Checklist
A practical pre-flight list for a Fabric rollout, covering workspace layout, capacity, governance and the decisions that are hard to reverse later.
Get the Checklist →
Building a Microsoft Fabric Lakehouse End to End The full path from an empty workspace to a Power BI report on a Microsoft Fabric Lakehouse, with the decisions called out at each point.
Step 1: Create the Workspace and the Lakehouse Sign in at app.fabric.microsoft.com and create a workspace backed by a Fabric capacity or a trial. Inside it, create a Lakehouse. Leave the Lakehouse schemas box ticked unless you have a specific reason not to, because the choice is close to irreversible.
If you are provisioning through the REST API instead, pass "enableSchemas": true in the creation payload. It is off by default there.
Step 2: Connect the Source Data Pick the ingestion path from Table 1 rather than by habit. If the source already lives in OneLake, ADLS Gen2, S3 or Google storage, create a shortcut and stop. If it is a scheduled pull from a database, build a Fabric data pipeline . If it arrives continuously, use an Eventstream.
Step 3: Attach the Lakehouse to a Notebook Open a notebook and add the Lakehouse from the explorer pane on the left, which sets it as the notebook’s default Lakehouse. Tables then appear grouped by schema, and dragging one into a cell generates a snippet carrying the right schema reference.
To use schema syntax in notebook code, the default Lakehouse must itself be schema-enabled, or there must be no default Lakehouse selected.
Step 4: Transform and Write Delta Read from the bronze source, apply the transformation, and write the result as a managed Delta table into the silver or gold schema. The write is saveAsTable with a schema-qualified name, and the table registers itself in the metastore on completion.
Moving a table between schemas or renaming it later is possible by drag and drop in the explorer. Everything referencing it then has to be updated by hand, including notebook code, dataflows and SQL queries.
Step 5: Serve It to Power BI Build a semantic model over the SQL analytics endpoint and select tables from any schema. Where two schemas hold tables with the same name, the model view appends numbers so you can tell them apart.
Remember that no default semantic model is created for you any more. Build the model deliberately, and model it properly, because a well-built Power BI layer is what the business actually sees.
Fabric Lakehouse vs Databricks Lakehouse The two share their foundations. Both are lakehouse architectures, both store Delta tables, both run Apache Spark, and both separate storage from compute.
The differences are about scope and fit. Databricks is a specialist data and AI platform with deeper support for advanced data engineering, machine learning at scale and multi-cloud deployment. Fabric is a single SaaS platform where the Lakehouse is one workload among warehousing, real-time intelligence, data science and Power BI. It integrates more tightly with Microsoft 365, Purview and Azure identity.
Organisations already standardised on Microsoft and buying analytics for the business tend to land on Fabric. Organisations with a large ML engineering function and multi-cloud requirements tend to land on Databricks. Plenty run both and connect them. We work through the trade-offs properly in Microsoft Fabric vs Databricks and cover the Databricks side in Databricks lakehouse architecture .
Datasheet
Snowflake vs Databricks vs Microsoft Fabric
A side-by-side look at the three platforms across architecture, workloads, governance and cost, for teams still choosing where the lakehouse lives.
Read the Datasheet →
Where Teams Get a Microsoft Fabric Lakehouse Wrong Five failure modes account for most of the rework we see on Microsoft Fabric Lakehouse engagements. Each one traces back to something earlier on this page.
Non-Delta files in the Tables area. The file sits there, the explorer shows it, and it never reaches the SQL analytics endpoint or Power BI. Convert to Delta and it appears.Schemas left off at creation. The Lakehouse cannot take row-level or column-level security, cannot use materialized lake views, and has no supported conversion path. This is the most expensive of the five because the fix is a rebuild.Small-file sprawl from streaming. Eventstream and frequent micro-batches produce thousands of small files, and every query pays for the metadata. Plan compaction before the first stream goes live.Copying the raw estate into bronze. Data already in OneLake, ADLS Gen2, S3 or Google storage belongs behind a shortcut. Copying it duplicates storage cost and introduces a staleness window that generates reconciliation work forever.One workspace for all three layers. It works until you need layer-level governance, separate deployment pipelines, or different access for the team that owns bronze and the team that owns gold. Splitting later means moving items and repointing everything that references them.On-Demand Webinar
Migrate to Microsoft Fabric 5X Faster with FLIP
A walkthrough of how our migration accelerators handle the repetitive conversion work when moving existing pipelines onto a Fabric Lakehouse.
Watch the Webinar →
How Kanerika Builds Microsoft Fabric Lakehouses That Hold Up Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics specialization and a Microsoft Fabric featured partner. Fabric Lakehouse work is a core part of what our data engineering teams deliver, and the approach below is what we actually run rather than a capability list.
How the Work Is Sequenced Assess. Inventory the sources, decide which of them become shortcuts rather than copies, and settle the schema and workspace layout before a single item is created. Getting the schema decision right here is what avoids the rebuild described above.Design. Set the medallion boundaries, the workspace per layer, the naming standard, and the security model down to row level where the business needs it.Build and migrate. Move pipelines and semantic models off the legacy platform, with our FLIP accelerators handling the repetitive conversion work on SSIS, Azure Data Factory, Informatica and Alteryx sources.Govern. Wire in lineage, sensitivity labelling and access review so the Lakehouse is auditable from the day it carries real data.Enable. Hand over to the internal team with the runbooks, the maintenance schedule and the runtime upgrade path documented.What That Looks Like in Delivery For a global thermal-management manufacturer, we built an Order Lead Time Analytics platform on Fabric across three disconnected SAP systems, Cloud for Customer, CPQ and S/4HANA. The build used medallion layering across development, test and production, and consolidated roughly 35 source tables into one structured foundation. Bridge logic connected opportunities, quotes and orders into a single continuous record. It carried the four-level row-level security described earlier. Reported outcomes were a 60% reduction in time spent per reporting cycle and 35 or more source tables connected across the order lifecycle. Fifty or more governed KPIs now standardise lead-time reporting.
Kanerika Case Study
60% Less Reporting Effort Across 3 SAP Systems on Fabric
How a global thermal-management manufacturer connected Cloud for Customer, CPQ and S/4HANA into one medallion Lakehouse with 50 or more governed KPIs.
Read the Case Study →
FoodPharma is a story Microsoft published with Kanerika named as the delivery partner. Six operational systems were unified on Fabric, consolidating more than 50 tables and roughly a terabyte of historical data. Cross-functional reporting went from two business days to 90 minutes. The BI team recovered around 15 hours a week of manual data work, and the implementation ran seven weeks end to end (Microsoft customer story, FoodPharma ).
A separate engagement migrated SSIS pipelines to Fabric using Fabric pipelines and PySpark notebooks. The reported results were a 30% improvement in data processing speeds and a 40% reduction in infrastructure and operational costs. Manual maintenance effort fell 25%, and data integrity held at 99.9% through the migration.
What We Watch For Three things get flagged in every review. Whether the Lakehouse was created with schemas. Whether bronze is shortcuts or copies. Whether anyone has looked at file counts since go-live. Those three questions predict the health of a Fabric Lakehouse better than any dashboard we have found.
Wrapping Up A Microsoft Fabric Lakehouse is straightforward to create and easy to get subtly wrong. The structure decisions are all made in the first week. Tables versus Files, schemas on or off, shortcuts versus copies, one workspace or three. Every one of them is expensive to reverse in the second year.
Get those right and the rest follows. One copy of the data in OneLake. Delta tables that every Fabric engine reads. A read-only SQL surface for the analysts, and a medallion structure that makes it obvious where a number came from.
Maybe you are standing one up now, or you inherited one that has started to misbehave. Our Microsoft Fabric consulting team does this work every week and is happy to look at yours.
Frequently Asked Questions
What is a Fabric Lakehouse? A Fabric Lakehouse is a Microsoft Fabric item that stores structured and unstructured data in one place. It keeps data in open Delta format inside OneLake, so Apache Spark and T-SQL both read the same copy. It provisions two folders, Tables for managed Delta tables and Files for everything else, plus a SQL analytics endpoint for read-only querying.
What is the difference between a data warehouse and Fabric? A traditional data warehouse is a structured store built for SQL analytics on relational data. Microsoft Fabric is a wider platform that contains a warehouse alongside data engineering, data science, real-time intelligence and Power BI. Fabric holds all of it in OneLake, so the warehouse becomes one workload on a shared foundation instead of a separate system.
Is data lakehouse ETL or ELT? Lakehouses mostly follow ELT. Raw data lands in storage first, then transformation happens in place using Spark or SQL. This suits a Fabric Lakehouse because bronze holds the data as it arrives, silver cleans it, and gold shapes it for reporting. Shortcuts push the pattern further by letting the bronze layer reference data without loading it at all.
Is Microsoft Fabric the same as Snowflake? They take different approaches. Snowflake is a cloud data platform centred on SQL analytics with strong multi-cloud support. Microsoft Fabric bundles storage, engineering, warehousing, real-time intelligence, data science and Power BI into one SaaS product tied to the Microsoft stack. Fabric bills through a single capacity while Snowflake separates storage and compute consumption.
What are the disadvantages of a data lake? Plain data lakes have no transaction guarantees, so concurrent writes can corrupt files. They carry no schema enforcement, which lets bad data accumulate quietly. Without a catalogue they become hard to search and the contents drift into a swamp. Query performance suffers because engines scan raw files with no statistics or indexes to work from.
What's the difference between a lakehouse and warehouse in Fabric? The Lakehouse stores structured and unstructured data, is built with Spark, and exposes a read-only SQL analytics endpoint. The Warehouse stores structured data, is built with T-SQL, and supports full read and write plus multi-table transactions. Both store open Delta in OneLake and share the same SQL engine, so the real split is tooling and transactions.
What is the difference between Azure Lakehouse and Fabric? Azure Lakehouse usually means a lakehouse assembled from separate Azure services such as Synapse, Data Lake Storage Gen2 and Databricks, wired together by hand. A Fabric Lakehouse is a single managed item with OneLake storage, a SQL endpoint and Spark already connected. The trade is less control over components in exchange for far less integration work.
Does Microsoft have a data lakehouse? Yes. The Fabric Lakehouse is Microsoft’s managed lakehouse, built on OneLake and Delta Lake. It stores Tables as managed Delta tables and Files in any format, registers tables automatically, and generates a SQL analytics endpoint for T-SQL querying. Spark notebooks, pipelines, dataflows and shortcuts all write into it, and Power BI reads from it directly.
What is Microsoft Fabric used for? Microsoft Fabric handles end-to-end analytics in one platform. Teams use it for data ingestion, engineering in Spark, warehousing in T-SQL, real-time intelligence over streaming events, data science, and reporting in Power BI. Everything writes to OneLake in Delta format, so a dataset built by one workload is readable by every other without an export step.
Which is better, Databricks or Microsoft Fabric? Neither wins outright. Databricks goes deeper on advanced data engineering, machine learning at scale and multi-cloud deployment. Fabric bundles lakehouse, warehouse, real-time and Power BI into one SaaS product with tight Microsoft 365 and Purview integration. Organisations already standardised on Microsoft tend to pick Fabric, and heavy ML engineering teams tend to pick Databricks.
How do I create a lakehouse in Microsoft Fabric? Sign in at app.fabric.microsoft.com and open a workspace backed by a Fabric capacity or trial. Create a new Lakehouse item and leave the Lakehouse schemas box ticked, because that choice is close to irreversible. Fabric provisions the Tables and Files folders and the SQL analytics endpoint automatically. Through the REST API you must pass enableSchemas explicitly.
How do I attach a lakehouse to a notebook in Microsoft Fabric? Open a notebook and add the Lakehouse from the explorer pane on the left, which sets it as the notebook default. Tables then appear grouped by schema, and dragging one into a cell generates a snippet with the right schema reference. Schema syntax works only when the default Lakehouse is schema-enabled or no default is selected.
What is the data lake in Microsoft Fabric? The data lake in Microsoft Fabric is OneLake, a single logical storage layer built on Azure Data Lake Storage Gen2. Every Fabric tenant gets one automatically. All Fabric items write into it. A Lakehouse in one workspace and a Warehouse in another end up as two folders in the same lake, with no copying between them.
What is the difference between a Fabric Lakehouse and OneLake? OneLake is the storage layer, provisioned once per tenant and shared by everything in Fabric. A Lakehouse is an item you create inside a workspace that occupies a folder in OneLake. One tenant has one OneLake and can have many Lakehouses. OneLake holds the bytes and the Lakehouse gives you tables, an explorer and a SQL endpoint.
Do I need lakehouse schemas in Microsoft Fabric? Enable them unless you have a specific reason to avoid them. Schemas group tables by business area and allow schema-level access control. They are also required for OneLake row-level and column-level security, materialized lake views and four-part cross-workspace queries. Microsoft ships no supported way to convert a Lakehouse built without schemas, so retrofitting means rebuilding.
Why is my table missing from the Fabric SQL analytics endpoint? Only Delta tables appear in the SQL analytics endpoint. A Parquet, CSV, ORC or Avro file placed in the Tables area shows up in the Lakehouse explorer. It stays invisible to T-SQL and to any Power BI model built on the endpoint. Convert the file to Delta format and it registers immediately with no other change needed.
Which Spark runtime should a Fabric Lakehouse use? Use Runtime 2.0 for production, which carries Apache Spark 4.1, Delta Lake 4.2, Python 3.13 and Java 21. Runtime 1.3 with Spark 3.5.5 has reached end of standard support. New workspaces still default to 1.3, so change it under Workspace Settings, Data Engineering and Science, Spark settings. Test JAR compatibility before you switch.
How many workspaces should a medallion lakehouse use? Microsoft recommends one workspace per layer, so bronze, silver and gold each live separately. A single workspace works at first and then makes layer-level governance, access control and deployment pipelines awkward. Splitting later means moving items and repointing everything that references them, so it is worth setting up correctly before any real data lands.
Can a lakehouse replace a data warehouse? A Fabric Lakehouse can replace a warehouse for many workloads, and its SQL analytics endpoint serves read-only T-SQL over Delta tables. It does not support multi-table transactions or the full warehouse T-SQL surface, which rules it out where those are required. Teams that need both often run a Lakehouse for engineering and a Warehouse for reporting.
What are the challenges of implementing a lakehouse? The common problems are structural. Non-Delta files land in the Tables area and never reach the SQL endpoint. Schemas get left off at creation, which blocks row-level security with no conversion path. Streaming ingestion produces small files that slow every query. Copying source data into bronze instead of using shortcuts duplicates storage and creates reconciliation work.
What is the purpose of a lakehouse? A lakehouse holds raw and curated data in one store so teams stop maintaining a lake and a warehouse side by side. Open Delta format gives ACID transactions, schema enforcement and version history on files. Engineers work in Spark and analysts work in SQL against the same tables, which removes the copy step and the reconciliation it creates.
When to use lakehouse vs warehouse in Fabric? Use a Lakehouse when your team develops with Apache Spark in Python, Scala, Spark SQL or R. It also suits data that mixes structured and unstructured content. Use a Warehouse when your team develops in T-SQL and needs multi-table transactions. Microsoft frames the decision around development style, transaction needs and data type. Storage is identical either way.
Is Microsoft Fabric a data warehouse or data lake? Microsoft Fabric is neither on its own. It is a platform that contains both, plus data engineering, data science, real-time intelligence and business intelligence. The Warehouse item gives relational warehousing in T-SQL. The Lakehouse item gives lake-scale storage with Spark and SQL access. Both write open Delta format into OneLake and can share a workspace.
Is Microsoft Fabric the same as Azure Data Factory? They are different products. Azure Data Factory is a standalone data integration service for building and running pipelines across Azure and external sources. Microsoft Fabric is a full analytics platform whose Data Factory workload carries forward much of that pipeline capability. Fabric adds storage, engineering, warehousing, real-time and Power BI in the same tenant.
What's the difference between a data lake and lakehouse? A data lake stores raw files in their native formats with no built-in transactions or governance. A lakehouse adds a table layer over those files, usually Delta, which brings ACID transactions, schema enforcement, version history and direct SQL access. The Fabric Lakehouse keeps the lake’s flexibility on any file type while making Tables behave like a database.
