Databricks, Snowflake, BigQuery or Fabric: how do you choose?

Databricks, Snowflake, BigQuery and Microsoft Fabric are four cloud data platforms in the same family, built to store and query large volumes of enterprise data, but with different architectural setups from the ground up. Snowflake manages storage in a proprietary way inside its own service. Databricks runs on a lakehouse built on open formats, inside storage the customer owns, with Spark as the compute engine and Delta Lake as the reference table format. BigQuery is a serverless engine integrated into Google Cloud, with no clusters to size or manage. Fabric consolidates every analytical workload onto a single lake, OneLake, where each engine reads and writes one copy of the data in Delta Parquet. None of the four setups is superior in absolute terms: each one trades off control, data openness and operational effort differently, and it is that trade-off, not one isolated feature, that determines which fits a given context better.

The difference that still matters

What stays stable, while the historical differences erode, is where the data physically lives by default. All four can now hold tables in open table formats inside customer-owned storage: Snowflake and BigQuery through Iceberg tables on external storage, Databricks as its native setting in Delta Lake, Fabric by writing Delta Parquet to OneLake. What changes is what happens when nobody decides anything: on Databricks and Fabric the data already sits in an open format, on Snowflake and BigQuery the native tables stay inside the service and the open configuration has to be chosen explicitly. In all four cases the friction of catalogs and pipelines remains, and no open format erases it. BigQuery and Fabric add the absence of clusters to administer, at the price of staying inside the Google Cloud and Microsoft perimeters respectively. On the distinction between a structured warehouse and a lake of raw files, the entry on data warehouse vs data lake applies.

The pricing comparison trap

The four platforms bill in different, non comparable units. Snowflake sells credits calculated on the usage time of its virtual warehouses. Databricks sells DBUs (Databricks Units), a unit that varies by workload type and by the underlying cloud it runs on. BigQuery bills through two models that differ from each other: on demand, on the bytes each query processes, or by capacity, in reserved slot-hours, so the unit changes even within a single platform. Fabric sells capacity in CUs (Capacity Units), a single pool covering every workload, with OneLake storage billed separately per gigabyte and outside the CUs. A quote comparing "Databricks cost" to "Fabric cost" without first normalizing the same workload is comparing units with no common denominator.

An enterprise example

An Italian manufacturing company with IoT-equipped plants generating millions of events a day evaluates the four platforms for its central data hub. If the group already sits inside a single cloud, with licenses and identities already there, the deciding criterion becomes integration friction, which pushes toward that cloud's native platform. If in-house skills are mostly SQL, an engine driven in pure SQL starts from a lower training cost; if instead pipelines are already written in Spark, rewriting them carries a cost the initial quote often leaves out. If the priority is running no infrastructure, a serverless engine cuts the load on the data team.

Why it matters for decision makers

The real criteria are three upstream questions. Which cloud the company already runs on, and what data residency constraints apply. Which skills already exist in-house, since training is a line item in both directions. How much it matters to physically own the data in an open format against how much it matters to maintain no infrastructure at all. And it applies equally to all four: vendor lock-in, present in each under a different shape (proprietary storage, compute units tied to a specific runtime, tight integration with a single cloud). Anyone looking for a model built around an operational ontology, rather than tables to query, is looking at Palantir Foundry, a further option that enters the same comparison once the problem is not purely analytical but operational.