Microsoft Fabric Lakehouse & OneLake - FAQs

Yes, Microsoft Fabric and Snowflake are genuinely comparable for the workloads most mid-market businesses actually run. Both are credible cloud data platforms, both use a lakehouse-style architecture, and both bill on consumption rather than fixed licence tiers. The differences are in ecosystem fit and specialisation rather than raw capability. Fabric's advantage is native integration with Power BI, Azure, and M365, plus OneLake as a single storage layer. Snowflake's advantage is genuine multi-cloud portability across AWS, Azure, and GCP, and a data-sharing model some organisations rely on for external data collaboration. Neither has a decisive edge in AI engineering specialisation over the other today. The decision is rarely about which is technically better. It is usually about which fits your team, your existing estate, and whether multi-cloud is a real requirement or a hypothetical one.

Microsoft Fabric, Snowflake and Databricks are a fair fight for most mid-market workloads, rather than one platform being obviously better. There are scenarios where one is obviously better and we cover those in the deck. Pure data warehouse performance at extreme scale tends to favour Snowflake. BI-led organisations on M365 tend to favour Fabric. In between, the decision is genuine and depends on your situation more than on the platforms.

Yes, Fabric, Databricks and Snowflake can be used together, and many estates do exactly that. OneLake shortcuts and mirroring let Fabric read data held elsewhere without copying it, so a common pattern is heavy engineering in Databricks or a warehouse in Snowflake, with Fabric and Power BI as the reporting and semantic layer on top.

There is more detail in Business Central to Microsoft Fabric: when it is worth it.

You cannot update table data through the lakehouse SQL analytics endpoint, because it is read-only for data. You can create views, functions and security rules. To change the data, write to the lakehouse with Spark, Dataflows Gen2 or pipelines, or use a Fabric Warehouse instead.

Power BI can report on data through a shortcut. Once a shortcut table appears in a lakehouse, a semantic model can use it like any other table, including in Direct Lake mode. The usual modelling work still applies, so the data should be shaped into facts and dimensions first.

Power BI can use Direct Lake with both lakehouses and Fabric Warehouses, because both store their tables as Delta in OneLake. Direct Lake reads those tables directly without importing them into the model. Our Power BI team can advise on when Direct Lake is the right storage mode.

A Fabric Warehouse can query lakehouse tables directly using cross-database queries with three-part names, because both store Delta tables in OneLake. No copy is needed, which makes it practical to use a lakehouse for Bronze and Silver and a Warehouse for Gold.

Other tools can read Delta tables stored in OneLake, because Delta is an open format and OneLake supports the same APIs as Azure Data Lake Storage. Fabric has also added interoperability with Apache Iceberg. See our Fabric, Databricks and Snowflake comparison for how the platforms relate.

Yes. You can move from Fabric to Snowflake later, or vice versa, with effort. Open table formats make data portability easier than it was. The harder parts are semantic models, BI tooling, security and the operational tooling around the platform. A migration is a real project, not a button-push, but it is no longer a one-way door. Choose well now and you will rarely need to migrate. Choose poorly and migration is a recoverable mistake.

You can use OneLake shortcuts with your existing Azure data lake. Creating shortcuts to Azure Data Lake Storage Gen2 makes the existing files and Delta tables usable in Fabric immediately, which is often the quickest first step in a move from Synapse or older Azure estates. See our Microsoft Fabric page for how we plan these moves.

On open table formats, both Fabric and Databricks support Delta. Databricks supports Iceberg natively. Fabric currently leans on Delta. Open formats reduce vendor lock-in and make migration easier. They do not decide the platform choice on their own. The interoperability story is improving fast on both sides.

In 2026 most mid-market businesses need a Fabric lakehouse as the starting point and a Fabric warehouse only where the workload is SQL heavy with complex joins and strict schemas. The choice should be made after looking at your data, not before, which is what the Establish phase is for. Lakehouse or warehouse and data warehouse, data lake or lakehouse set out the trade offs.

Often not. OneLake shortcuts let you point at data that already lives elsewhere, another lake, another cloud or another workspace, and query it in place as if it were local. For many problems a shortcut removes the need for a migration project entirely.

For the full picture, see OneLake explained: one copy of your data, and what a shortcut actually is.

OneLake shortcuts do not copy data. The data stays in its original location and Fabric reads it in place. For some external clouds, such as Amazon S3 and Google Cloud Storage, Fabric can cache files temporarily to reduce egress costs, but the source remains the master copy.

No, warehouse snapshots do not support Direct Lake semantic models. They require DirectQuery or Import mode in Power BI, so estates whose reporting is built on Direct Lake over the warehouse need a different approach, usually controlled framing after validation rather than snapshots.

No, you do not need Databricks to build a lakehouse on Azure. Microsoft Fabric with OneLake gives most mid-market businesses a governed lakehouse using Delta tables, with Direct Lake connectivity into Power BI, without the operational demands of Databricks. Databricks is the stronger choice when heavy Spark engineering or machine learning at scale is the core workload.

We go into this further in Data warehouse, data lake or lakehouse: which one your business actually needs.

Most mid-market businesses need a Fabric lakehouse rather than a separate warehouse: it stores structured and semi-structured data in Delta tables, feeds Power BI through Direct Lake, and scales without a second engine; a Fabric warehouse is the better fit when the workload is SQL-heavy with strict schema and multi-table transactions. We decide in the Establish phase. See the layered lakehouse explained.

No. Snowflake and Databricks both run across AWS, Azure and GCP, which matters for multi-cloud strategies or avoiding single-vendor lock-in. Fabric is a Microsoft platform, its tight single-vendor integration with Azure, Power BI, Purview and Entra ID is its main strength if you are already all-in on Microsoft, and a genuine constraint if you need cross-cloud flexibility.

We go into this further in Business Central to Microsoft Fabric: when it is worth it.

Yes, vacuuming can break Direct Lake models. A framed model is bound to a specific Delta commit version, so if vacuum removes the files that version depends on, users get query errors rather than slow queries. Vacuuming should therefore be a scheduled, coordinated step rather than an occasional ad hoc task. Our Microsoft Fabric page covers how we deliver it.

To improve Direct Lake query performance, use incremental merge loads rather than overwrites so framing stays incremental, consolidate small Parquet files and apply V-Order during optimisation, ensure the capacity has memory headroom so segments are not evicted, and consider a scheduled warm-up query after the refresh so the first real user does not pay the cold start cost.

Snowflake has had a longer head start on cross-organisation data sharing through Snowflake Marketplace and direct sharing. Fabric is catching up through OneLake shortcuts and external sharing. If multi-organisation data sharing is core to your business model, this currently favours Snowflake. For most mid-market businesses, it is a non-issue.

On open table formats, both Fabric and Snowflake support Delta Lake. Snowflake also supports Iceberg natively. Fabric uses Delta as the storage format underneath the Lakehouse component. Open formats reduce vendor lock-in and make some migration scenarios easier, but they do not decide the platform choice on their own. The decision is mostly about platform fit, not file format.

To stop OneLake sprawling, treat copying as the exception, not the habit. The useful discipline is to ask, each time someone is about to extract a dataset, whether a shortcut would do instead. Asked often, that one question is how an estate gets simpler rather than messier over time.

It is worth reading our guide to OneLake explained: one copy of your data, and what a shortcut actually is.

Microsoft Fabric and Databricks are both lakehouse platforms and handle the lakehouse architecture similarly. Databricks invented the term and the architecture. Fabric implements lakehouse via OneLake using Delta as the storage format. The architectures are functionally similar. The differences are in tooling, governance and the surrounding ecosystem. Both let you store once and query many ways. The platform decision is rarely about the lakehouse architecture itself.

Microsoft Fabric and Snowflake handle identity and governance differently, mainly in how the integrations are delivered. Fabric is native to Entra ID, Purview and M365 Sensitivity Labels. The governance story is genuinely tighter for organisations already on M365. Snowflake supports the same integrations but they are plumbed in rather than built in. The difference is operational rather than functional. Day-to-day, Fabric requires fewer touchpoints. For organisations with mature governance functions, the difference is smaller. For organisations relying on out-of-the-box governance, it is larger.

Each layer is a set of Delta tables in dedicated lakehouse workspaces or schemas. Bronze tables are append-only with transaction timestamps. Silver tables are mutable with merge logic for deduplication. Gold tables are typically rebuilt or merged depending on the modelling pattern. Direct Lake mode in Power BI reads Gold tables directly without copying. The Delta Lake format provides ACID transactions, schema evolution, and time travel across all three layers. The technology supports the pattern cleanly; the discipline is in the design.

You stop a Fabric Lakehouse becoming unmaintainable by keeping bronze append-only, replacing per-source pipelines with one metadata-driven pipeline and control table, using bounded idempotent incremental loads, decomposing orchestration into testable child pipelines, and scheduling optimise and vacuum as part of the build rather than as occasional housekeeping.

Delta Lake tables in OneLake keep a transaction log and version history for every change, so a pipeline can be pointed back at an earlier point in time and reprocessed deterministically. Combined with version-controlled notebooks or Dataflows Gen2, that history is what makes a genuine end-to-end replay possible rather than just a restore from backup.

Direct Lake mode changes the architecture significantly. Direct Lake reads Power BI data directly from Delta tables in OneLake without import or pass-through. The result combines Import-mode performance with near-real-time freshness because the lake is the storage layer rather than a separate copy. For new Fabric implementations, Direct Lake is the default for most semantic models. The exceptions are models that need calculated columns or complex DAX patterns that Direct Lake does not yet support, in which case Import mode remains the right choice.

Fabric bills on fixed capacity (an F-SKU covering all workloads from one meter), predictable, pausable, but a shared pool that can be contended and can mean paying for unused reserved capacity. Snowflake and Databricks bill on consumption (Snowflake credits-per-second with auto-suspend; Databricks DBUs plus cloud compute), efficient for spiky, intermittent workloads but capable of surprising you if large jobs run unwatched. Fixed capacity favours steady mixed workloads; consumption favours variable, bursty ones. Neither is cheaper in the abstract.

Related reading: Business Central to Microsoft Fabric: when it is worth it.

Hopton helps you choose between the platforms in two ways. A decision review, two to three weeks at fixed price, where we walk a structured framework with your team and produce a written recommendation. Or, if you have already chosen Fabric, full delivery: architecture, build, governance and training. We do not deliver Snowflake projects ourselves. If Snowflake is the right answer, we will tell you and can introduce you to people who do.

OneLake works with Business Central data today through an extraction such as bc2adls or the standard connectors that land Business Central tables as Delta files in a lakehouse, and in future through Business Central mirroring, which Microsoft announced at FabCon Europe in October 2026 with a public preview expected in a 29.1 update and which will replicate the ERP into OneLake with no pipeline. Once the data is in OneLake, Power BI reads it through Direct Lake. Business Central to Fabric in zero ETL steps covers what mirroring will change.

Snowflake handles multi-cloud natively. Snowflake runs on AWS, Azure and GCP and supports cross-cloud data sharing. If your organisation has workloads across more than one cloud, this is a genuine advantage. Fabric is Azure only and pulls Azure-adjacent workloads with it. Multi-cloud strategy is rarely a small consideration when it applies.

OneLake is different from Azure Data Lake Storage because it is provided automatically with Fabric, one per tenant, and is shared by every Fabric engine. It is built on the same underlying technology and supports the same APIs, but you do not provision or manage separate storage accounts for each project.

OneLake is different from what you already have because it is the unified storage layer underneath every Fabric workload. One copy of the data, in open Delta format, accessible by all Fabric tools without copying or moving. This is genuinely different from previous Microsoft data platforms where Power BI had its own storage, Synapse had its own, and integrations meant duplicating data. The 'one copy' principle reduces storage cost, simplifies governance, and removes the synchronisation work that previously consumed engineering time. For most mid-market implementations, OneLake is the architectural feature with the highest practical impact.

Snowflake is priced per credit of compute while a virtual warehouse runs, at $2.70 per credit on Standard and $4.00 on Enterprise in Azure UK South on demand, plus $24 per terabyte per month of storage, with the BI tool bought separately; Microsoft Fabric is priced as a capacity that is on continuously, from £138 a month reserved, with Power BI included. An extra-small Snowflake warehouse uses one credit an hour and each size doubles it. How to choose a Microsoft Fabric consultancy explains what to ask a partner about cost.

A lakehouse stores data as open Delta Parquet files in a data lake and applies warehouse-style structure, transactions and SQL on top, so the same files serve Spark, SQL and Power BI without copying; a traditional data warehouse stores data in a proprietary database engine that only SQL can read. In Fabric the two converge, because the warehouse and the lakehouse both store Delta tables in OneLake. Lakehouse or warehouse? sets out when each wins.

A modern lakehouse differs from a traditional data warehouse in three structural shifts. Traditional warehouses combined storage and compute in a single appliance; modern lakehouses separate them, storing data once in cloud object storage and applying compute on demand. Traditional warehouses kept only structured business-ready data; lakehouses keep raw data alongside transformed data, supporting machine learning and exploration alongside reporting. Traditional warehouses were schema-on-write (transformations happened on the way in); lakehouses are schema-on-read or hybrid, allowing schema evolution without rebuilding the warehouse. Each shift reduces operational pain and increases flexibility.

Delta files should be consolidated through optimisation toward roughly 1 GB blocks and written with V-Order encoding. Fewer, larger, well-compressed files reduce the number of Parquet chunks and dictionaries Direct Lake must merge during transcoding, and V-Ordered data can in some cases be computed over directly without decompression.

Snowflake works well with Power BI, but as two systems. Power BI connects to Snowflake via the standard connector and works fine. The integration is solid. What you do not get is the unified experience Fabric provides: shared semantic models, shared identity, integrated lineage. For most mid-market workloads, that integration tax is real but manageable. For BI-led organisations, the tax adds up over time.

No, Direct Lake isn't always faster than DirectQuery or Import. Direct Lake is the right default for most Fabric reporting because it gives near-Import speed without a full import refresh. It still has limits. Very large tables can exceed what a capacity allows Direct Lake to hold. Direct Lake models built on a SQL endpoint can quietly fall back to DirectQuery when that happens, and those built directly on OneLake simply fail. For high-concurrency workloads, such as many users or AI agents firing queries at once, DirectQuery against a Fabric Warehouse with its newer GPU-accelerated query options can outperform Direct Lake. Import still has a place for small, stable models that need the fastest possible response. The right answer depends on volume, concurrency and freshness, and should be chosen deliberately. Our guide to lakehouse SQL endpoint or Fabric Warehouse covers the storage side of that choice.

None is universally better; they fit different workload shapes. Fabric suits Microsoft-centric mid-market businesses wanting one integrated platform and one bill, with mainstream analytics needs and governance through existing Microsoft tooling. Databricks suits heavy data engineering and machine learning at scale with a notebook-first team. Snowflake suits warehouse-first, SQL-centric workloads that benefit from elastic consumption pricing and cross-cloud independence. The right choice depends on your workloads, your usage shape, and where your team already works.

It is worth reading our guide to Business Central to Microsoft Fabric: when it is worth it.

Microsoft Fabric is usually cheaper than Databricks or Snowflake for a mid-sized Microsoft business on the licence line, because Power BI, governance and data engineering share one capacity from £138 a month reserved, whereas Databricks is billed per DBU plus virtual machines and Snowflake per credit from $2.70 on Standard; the build cost is similar on all three. See the full UK price comparison.

Microsoft Fabric is usually cheaper than Databricks or Snowflake for a mid-market business whose questions are finance, sales and operations across a handful of systems, because one capacity does the engineering and serves the reports, and at F64 the viewers are free. Databricks or Snowflake can be cheaper for heavy, bursty engineering at large volume with a small reporting audience, because they charge only while the engine runs. Fabric, Databricks, Snowflake: a capability by capability comparison covers the rest of the decision.

On warehouse-shaped workloads, Snowflake is often faster than Fabric. On the round trip from raw data to a dashboard a business user opens, less often. The benchmark wars are real but mostly relevant at scale most mid-market businesses do not reach. For a typical mid-market workload, both platforms are fast enough. The performance difference matters most when you are running enterprise-scale analytical queries continuously.

A lakehouse is not always better than a data warehouse. A lakehouse wins when you have mixed workloads such as BI alongside engineering or data science, growing volume or variety, and a genuine need for one governed copy of the data. Where the data is structured and stable and BI is the only consumer, a well modelled warehouse is simpler and cheaper to run.

If you are weighing the options, our guide on which one your business actually needs walks through how to choose between a data warehouse, a data lake and a lakehouse.

Choosing between a warehouse, a data lake and a lakehouse is a business decision dressed up as a technical one. It shapes what your estate can do, what it costs to run, and how much flexibility you keep for questions you have not thought of yet, so it should be made against what the business needs to answer rather than on architectural preference.

It is worth reading our guide to Lakehouse or warehouse? The Azure architecture patterns that actually hold up.

No. OneLake stores data in the open Delta and Parquet formats, which other tools can read. Keeping your data in open formats is a quiet insurance policy against lock-in, and it is one of the better reasons to adopt OneLake deliberately rather than by accident.

There is more detail in OneLake explained: one copy of your data, and what a shortcut actually is.

Use a Lakehouse for most cases. The Lakehouse stores Delta tables in OneLake, which all the other Fabric workloads can read directly. It supports notebooks (Python, Spark) for transformation and runs Power BI semantic models with Direct Lake mode for high-performance reporting without copying data. The Warehouse is better when your team works in SQL exclusively, when you have specific T-SQL requirements, or when performance characteristics demand it. Most mid-market implementations use the Lakehouse as the default with the Warehouse for specific workloads.

Microsoft Fabric, Snowflake and Databricks compare mainly on which workload each handles best. Snowflake excels at elastic, multi-cloud SQL warehousing and data sharing. Databricks leads for large-scale data engineering and machine learning on the lakehouse. Microsoft Fabric excels when you are Microsoft-centric and want data integration, warehousing, governed self-service BI in Power BI, and AI in one platform rather than integrated afterwards. Choose by your dominant workload, warehouse-first, ML-first, governance-heavy, or multi-cloud, rather than by brand.

Whether to transform data before or after loading it into OneLake depends on the kind of rule you are applying. Compliance controls such as masking personal data, enforcing types and removing duplicates belong before the load, because once a raw copy exists in OneLake it can be queried. Business rules that change often, such as customer hierarchies or the definition of gross margin, belong after the load, in one governed place in the Warehouse or gold layer under version control, so that a change to the rule changes the number everywhere at once. For the reasoning behind this split, read our post on when to transform data in Fabric, and for the tool choices see the Fabric data integration decision guide.

Whether to use a Fabric Warehouse or a lakehouse for your Gold layer depends mainly on your team's skills. SQL developers are usually most productive building the Gold star schema in a Warehouse. Spark and Python teams often keep Gold in a lakehouse. Both work well with Power BI.

Reports should read from the gold layer through the semantic model, never from silver. Silver holds cleaned data but not the business definitions, so a report that reads it has to define margin, ageing or utilisation itself, and no two reports will agree. Gold holds those definitions once, and the semantic model exposes them. Data model or ontology? explores the meaning layer in more depth.

OneLake shortcuts in Microsoft Fabric let you use data held in other storage and platforms without copying it into Fabric. They help businesses that already run more than one platform bring their data together without a large migration.

Materialized lake views in Microsoft Fabric are transformations defined in Spark SQL whose results Fabric stores as Delta tables and refreshes automatically, in dependency order, incrementally where possible and not at all when nothing has changed. They can include declared data quality rules and suit medallion architecture layers.

The Direct Lake residency states are cold, semiwarm, warm and hot, with increasingly better performance from cold to hot. Cold means the VertiPaq store is empty, semiwarm means some segments have been dropped through framing or memory pressure, warm means the required column data is loaded, and hot means the data is loaded and the VertiScan caches are populated. Our Microsoft Fabric page covers how we deliver it.

The bronze layer holds raw data exactly as it arrived from the source with load date and origin recorded, so it can be replayed; the silver layer holds the same data cleaned, typed, deduplicated and conformed across systems with quality checks applied; and the gold layer holds the star schema of fact and dimension tables with business measures defined once, which reports and semantic models read. From Business Central to Fabric: the medallion architecture blueprint shows the pattern applied to an ERP.

Snowflake is a cloud data warehouse that has expanded into a broader data platform. It separates storage and compute, runs on AWS, Azure or GCP, and is known for elastic scaling. It also handles data engineering, data sharing, and increasingly data science workloads. Snowflake is platform-neutral about your BI tool: Power BI, Tableau, Looker, and others all work on top.

Snowflake cost is consumption-based. You pay for compute when queries run and storage for data at rest. Costs are visible per query, less predictable per month. Mid-market organisations often land on a few hundred to a few thousand pounds a month, depending on workload patterns. Spiky workloads can be cheaper than fixed Fabric capacity. Steady workloads are often more expensive.

The decision review for a Fabric vs Snowflake choice covers workload analysis, team and skill assessment, estate review, weighted scoring against the six dimensions in the comparison deck, and a written recommendation. Output is a document you can take to anyone, including in-house or another partner. The review is independent of any subsequent build engagement. About half of decision reviews end with us not doing the build, and that is fine.

Each layer of a medallion architecture holds data at a different stage: Bronze contains raw data exactly as extracted from source systems. JSON files from APIs, CSV exports, database snapshots, change logs. The format preserves source structure even when awkward. Silver contains cleaned data with deduplication, standardisation, and quality rules applied. Customer records are unified, product codes are consistent, dates are normalised. Gold contains business-ready facts and dimensions with the modelling decisions made. Sales fact tables, customer dimensions, time-intelligence dates. Power BI semantic models consume from Gold; ML notebooks usually consume from Silver or Gold depending on the use case.

Azure Data Lake Storage Gen2 is object storage optimised for analytical workloads. It is the storage layer underneath traditional Azure data architectures (ADF plus Synapse plus Power BI). For new builds, OneLake within Fabric is usually the right choice instead, because it provides similar capability with cleaner integration to the rest of the analytical stack. ADLS Gen2 remains the right choice when you have specific tooling that integrates with it directly, when you need to share storage across non-Microsoft analytical tools, or when existing investments make migration impractical.

Delta Lake is an open table format that turns a folder of Parquet files into a reliable table by adding a transaction log. The log records every change in order, which provides reliable writes, schema enforcement, time travel and support for updates, deletes and merges.

Direct Lake lets Power BI read Delta tables in OneLake directly, without importing or copying the data into the model. It matters because it removes the extra copy of data that traditional import mode creates, which is precisely the duplication a lakehouse is meant to eliminate. Importing your gold tables anyway quietly reintroduces the problem.

For the full picture, see Data warehouse, data lake or lakehouse: which one your business actually needs.

Direct Lake is a Power BI query mode unique to Microsoft Fabric. It allows Power BI to query data directly from the OneLake delta parquet files without importing or caching the data, and without the latency of a live DirectQuery connection. The result is near-import-speed performance on data that is always current, removing the trade-off between performance and freshness.

Microsoft OneLake is the single data lake that sits under every Microsoft Fabric workload, storing each table once in open Delta Parquet format so pipelines, notebooks, the warehouse, Real-Time Intelligence and Power BI read the same files without copying. It works through workspaces that each have a place in the one lake, shortcuts that point at data held elsewhere without moving it, and mirroring that replicates operational databases into it. What is Microsoft Fabric? explains how OneLake fits the platform.

OneLake in Microsoft Fabric is the single, organisation-wide data lake that every Fabric workspace, lakehouse, warehouse and mirrored database stores its data in. Each tenant has exactly one. Because every Fabric engine reads the same tables in the same open format, data can be stored once rather than copied between services.

OneLake is the single storage layer under every Fabric workload: one copy of each table in Delta Parquet that the lakehouse, warehouse, notebooks, Power BI and real-time engines all read, with shortcuts to data left in ADLS, S3 or Dataverse rather than copied. See OneLake in plain English.

A Delta change data feed is an option on a Delta table that records the rows inserted, updated and deleted by each change to the table. Downstream processes, such as notebooks and materialized lake views in Fabric, can read only those changes instead of reprocessing the whole table.

A OneLake shortcut is a pointer that makes data stored elsewhere appear as a folder or table inside Fabric, without copying it. Shortcuts can point at other OneLake locations, Azure Data Lake Storage, Amazon S3, Google Cloud Storage, Dataverse, SharePoint and on-premises storage through a gateway.

A Parquet file is an open file format that stores data by column rather than by row. Analytics queries only read the columns they need, and similar values stored together compress very well, so Parquet files are much smaller and faster to query than CSV. Parquet on its own has no concept of a table or transactions.

A layered lakehouse architecture stores data in open Delta Parquet files in a data lake and organises it into layers with one job each: bronze holds raw data exactly as it arrived, silver holds cleaned and conformed data with quality checks, and gold holds the star schema modelled in business terms, with a semantic model on top. Data moves in one direction and each layer can be rebuilt from the one below. Medallion architecture in practice covers the build.

A medallion architecture organises data into three progressively refined layers inside OneLake. Bronze holds an unaltered copy of what arrived from the source system. Silver holds that data once it has been validated, deduplicated and modelled at a usable grain. Gold holds business-ready, curated datasets built specifically for reporting and analytics. Each layer has a distinct job, so a problem at one stage rarely means rebuilding the whole pipeline.

Framing in a Direct Lake semantic model is the metadata-only operation that binds the model to a specific committed version of the underlying Delta tables. No data is copied, which is why it is fast, and framing can be incremental so that in-memory data which is still valid is reused rather than discarded.

Medallion architecture is a data organisation pattern with three layers: Bronze (raw data ingested from source systems, unchanged), Silver (cleaned, deduplicated, conformed data ready for analytical use), and Gold (business-ready data with the modelling, aggregations, and semantic structure for reporting and analytics). Each layer has a defined purpose, defined ownership, and defined consumption patterns. The pattern was popularised by Databricks but applies equally to Microsoft Fabric implementations.

The SQL analytics endpoint in a Fabric lakehouse is a read-only T-SQL interface created automatically with every lakehouse. It lets people and reporting tools query the lakehouse's Delta tables with SQL, and supports views, functions and security rules, but not inserting, updating or deleting table data.

The difference between Delta and Parquet is that Parquet is a file format for storing data by column, while Delta is a table format built on top of Parquet files. Delta adds a transaction log that tracks which files make up the current table, giving database-style reliability and history.

The difference between Direct Lake on SQL and Direct Lake on OneLake is fallback behaviour. Direct Lake on SQL can fall back to DirectQuery against the SQL analytics endpoint when a query cannot be served from memory, which is slower and introduces hybrid query plans, while Direct Lake on OneLake never falls back and fails the query instead. The choice is an architecture decision about whether a slowdown or a clear failure is easier to govern.

The difference between a Fabric lakehouse and a Fabric Warehouse is how data is written. A lakehouse is written by Spark, dataflows, pipelines or mirroring and queried in SQL through a read-only endpoint. A Warehouse supports full T-SQL writes, stored procedures and multi-table transactions. Both store Delta tables in OneLake.

The difference between a data warehouse and a data lakehouse is that a warehouse stores structured, modelled tables inside a database engine that only SQL reads, with strict schema and transactions, while a lakehouse stores open Delta Parquet files in cloud storage that behave like tables and that SQL, Spark, Python and Power BI read without copying, with schema applied through bronze, silver and gold layers. In Microsoft Fabric both sit on OneLake and can be used together. See the layered lakehouse explained.

The difference between a data warehouse and a data lakehouse starts with what each one holds. A data warehouse stores structured, modelled data optimised for fast, reliable reporting and dashboards, it is the trusted, governed layer that business intelligence tools query. A data lakehouse combines a data lake’s ability to hold raw and semi-structured data cheaply at scale with warehouse-style structure and governance on top, so you can run both BI reporting and data science or machine learning from one platform. In the Microsoft stack, Microsoft Fabric and OneLake bring lakehouse and warehouse capabilities together, which is why the choice is less either-or than it used to be. For most mid-market businesses the practical question is not the label but how to build a single, governed analytics layer that Power BI can report from reliably. Hopton Analytics designs and builds cloud data platforms on Azure and Microsoft Fabric for UK mid-market businesses.

The difference between the Bronze, Silver and Gold layers is the job each one does to the data. Bronze is the ingestion layer: an immutable, as-is copy of source data, kept exactly as it arrived so nothing is lost or reinterpreted too early. Silver is the validation layer: records are deduplicated, conformed to agreed types and keys, checked against quality rules, and modelled at a clear grain. Gold is the consumption layer: business logic, aggregations and denormalisation are applied so the data is shaped for a specific report, semantic model or downstream application. Responsibility moves from preserving truth, to cleaning it, to presenting it.

The medallion (bronze, silver, gold) architecture is a way of organising a data platform into three layers, each with one job. Bronze is raw, immutable landing that preserves data exactly as it arrived along with its ingestion metadata, which makes reprocessing possible. Silver is cleaned and validated, deduplicated, schema-standardised, quality-checked. Gold is business-modelled and analytics-ready, feeding semantic models and reports. Because each layer has a clear responsibility, you get end-to-end lineage, auditability and the ability to replay history from source.

The medallion architecture is a layered pattern, bronze (raw), silver (cleaned and conformed), gold (business-ready), where data only ever moves downstream. It keeps your raw data replayable, applies business rules once in the silver layer, and shapes gold tables for specific consumers like Power BI. It is the pattern behind most well-built Azure lakehouses.

For a deeper look, see our guide to Data warehouse, data lake or lakehouse: which one your business actually needs.

Time travel in Delta Lake is the ability to query a table as it was at an earlier version or point in time, using the history kept in the transaction log. It is useful for auditing changes, checking what a load did and recovering from mistakes, within the retention period the table keeps. Our Microsoft Fabric page covers how we deliver it.

Transcoding in Direct Lake is the on-demand conversion of Parquet column chunks into the VertiPaq in-memory format when a query needs data that is not yet resident. It merges Parquet dictionaries into one global dictionary, loads column segments, builds join indexes for relationships and applies Delta deletion vectors, and it happens per column rather than for the whole table.

The bronze layer should contain raw, append-only data exactly as the source sent it, with load timestamps and source metadata added but nothing cleaned, cast or dropped. Treating bronze as a tape recorder rather than an editor gives you provenance for disputed numbers, replayability when a transformation bug is found, and history that survives the source system being replaced.

Data is typically transformed from Bronze to Gold in Microsoft Fabric through Dataflows Gen2, for lower-code, business-owned logic, or notebooks running Spark for more complex engineering work. Data Factory pipelines orchestrate the sequence, triggering Bronze ingestion, then Silver validation and cleansing, then Gold aggregation, on a schedule or an event trigger. Everything lands as Delta tables in OneLake, and it is the Gold layer that a certified semantic model reads from directly using Direct Lake mode in Power BI, without duplicating the data again.

Snowflake is clearly the right answer in three scenarios. Multi-cloud or AWS-first estates, because Fabric is Azure only. Heavy data engineering teams who prefer SQL-first, code-led tooling. And spiky, unpredictable query workloads, where Snowflake's per-query consumption model fits better than Fabric's fixed capacity. If any of these describe you, Snowflake is the better starting point.

You should copy data instead of using a shortcut when you need to transform it, keep an untouched historical record, protect reports from changes at the source, or when reading across clouds is too slow or costly. Shortcuts are ideal for sharing curated data and bringing existing lakes into Fabric quickly.

Use a OneLake shortcut when the data lives in files or object storage such as ADLS, S3 or GCS, another team owns it, and you can consume it as it is. A shortcut is a zero-copy, read-only reference with no refresh to fail and no duplicate to drift, but it gives you no transformation layer and performance depends on the source file layout.

Governance and monitoring fit across every layer of a lakehouse architecture rather than at the end: Microsoft Purview catalogues and classifies data in all layers, OneLake security applies access rules at the storage layer so they hold in every engine, Fabric policies set tenant and capacity rules, and workspace monitoring and the capacity metrics app show what ran, what failed and what consumed capacity. Microsoft Fabric governance in 2026 covers the controls.

Whether Microsoft Fabric or Snowflake is cheaper overall is highly situation-specific. Both can be cheaper. Fabric tends to be cheaper for steady BI-led workloads on M365 because Power BI licences flow in and capacity is predictable. Snowflake tends to be cheaper for spiky workloads where compute can scale to zero. The total cost picture also includes integration cost, training and team operability, and those often outweigh raw platform cost.

None of the three is reliably cheapest, because they bill differently and the cheapest option depends on your workload shape. Fabric sells reserved or on-demand capacity, Databricks and Snowflake bill compute by use, so steady predictable load tends to suit reserved capacity while spiky or occasional load tends to suit consumption billing. Model your own pattern rather than comparing headline rates.

For the full picture, see Business Central to Microsoft Fabric: when it is worth it.

The people who can see data through a OneLake shortcut are those with permission on the shortcut's location and on the target data. For external storage, access runs through a connection whose credentials must be owned and governed. Shortcut security should be designed deliberately rather than left to whoever creates them.

Only the ingestion pipelines themselves should be able to write to the Bronze layer in a well-run Fabric estate, never analysts or ad hoc scripts editing files directly. Restricting write access to the automated pipeline is what keeps the layer trustworthy as a permanent record, and it's usually enforced through workspace roles and OneLake access policies rather than convention alone.

You may not see a new lakehouse table in the SQL analytics endpoint straight away because the endpoint syncs lakehouse metadata automatically but can lag slightly behind Spark writes. The table normally appears shortly afterwards. Processes that write and immediately read should allow for this.

Direct Lake performance usually gets worse after an ETL change because the load pattern changed from an incremental merge to a destructive overwrite, which prevents incremental framing and sends a warm model fully cold after every refresh. Other common causes are a change in Parquet file counts or sizes, missing V-Order optimisation, and memory pressure on the capacity.

Delta tables need optimising and vacuuming because frequent loads create many small files and leave old files behind. Optimise combines small files into larger ones for faster reads. Vacuum removes files no longer referenced, which saves storage but limits how far back time travel can go.

Microsoft Fabric uses Delta tables because an open, shared format lets every Fabric engine, including Spark, SQL and Power BI in Direct Lake mode, read the same copy of the data. It avoids duplicating data between services and avoids locking data into one proprietary format.

The staging lakehouse matters in Dataflow Gen2 because it is what makes computed entities and query folding work correctly. Disabling staging to make a dataflow feel faster often makes the overall solution slower and breaks folding, pushing transformation work back to the client instead of down to the source.

The first Direct Lake query of the morning is slow because nothing is resident in memory after an overnight refresh, so that query pays the transcoding cost of loading every column it touches from Parquet into VertiPaq, including the key columns needed to build join indexes. Subsequent queries find the columns already loaded and run at the expected speed.

You can trust our Fabric vs Snowflake comparison, even though we are a Microsoft consultancy, for two reasons. We do not benefit from selling you the wrong platform. A failed Fabric project costs us reputation and renewal far more than a clean Snowflake recommendation costs us in lost revenue. And we have actively recommended Snowflake to clients where it was the right answer, including to clients who came to us assuming Fabric was the inevitable choice. The recommendations and the rationale are documented and we are happy to walk through them.