Microsoft Fabric Lakehouse & OneLake - FAQs

Yes, 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.

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.

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.

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.

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.

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.

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.

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.

Both Fabric and Databricks are 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.

OneLake 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 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.

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.

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.

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.

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.

In a medallion architecture, 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.

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.

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.

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.

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.

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.

Transformation typically happens 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.

In a well-run Fabric estate, only the ingestion pipelines themselves write to Bronze, 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 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.