Snowflake vs Databricks

Snowflake's documentation describes 3 layers. Database storage keeps loaded data in Snowflake's own compressed columnar format, divided into micro-partitions. Compute comes from virtual warehouses, each an independent cluster that shares no compute with the others, so a heavy job on 1 warehouse does not slow another. A cloud services layer handles sign-in, security, metadata and query optimisation.

Databricks builds its lakehouse on Apache Spark with compute decoupled from storage. Tables are Delta Lake files in cloud object storage, which add ACID transactions and schema enforcement to plain files, and Unity Catalog governs tables, views, volumes, functions and models through a catalog.schema.object namespace. Compute is a cluster or a SQL warehouse, and serverless SQL warehouses leave capacity and upgrades to Databricks.

The practical consequence is who holds the data. In the default Snowflake design the data sits in Snowflake's managed storage and you reach it through Snowflake. In the default Databricks design the files sit in a storage account you own, and any engine that reads Delta can open them. Both vendors now blur this line, as the section on open table formats shows.

Both charge for consumption, in different units. Snowflake bills credits. The warehouse documentation lists a Gen1 standard warehouse at 1 credit per hour for X-Small, doubling with every size up to 512 credits per hour for 6X-Large. Billing is per second with a 60 second minimum each time the warehouse starts, and auto-suspend is on by default. Databricks bills Databricks units (DBUs), a normalised unit of processing power, per second, and storage and networking are charged separately.

The minimum matters for bursty work. A 20 second query that resumes an X-Small warehouse is billed for 60 seconds, or 0.0167 credits instead of 0.0056, 3 times the work done. A dashboard that wakes a warehouse every few minutes pays that minimum again and again, while a warehouse that stays busy never notices it.

Size and runtime trade against each other. A 10 minute job on a Medium warehouse at 4 credits per hour costs 0.667 credits. If the same job scales linearly and finishes in 5 minutes on a Large warehouse at 8 credits per hour, it costs 0.667 credits, the same bill for an answer twice as fast. Jobs rarely scale perfectly, so test the larger size against your own query before you assume it.

Databricks has the same trade, with extra choices about how compute is provided. Serverless compute leaves infrastructure to the vendor. Classic compute runs in your own cloud account, where the provider also charges you for the instances. Because the units and the infrastructure split differ, the rate cards cannot be compared directly. Run the same representative workload on both and compare the invoices.

Snowflake supports Apache Iceberg tables, which keep Parquet files in cloud storage you manage and bring Snowflake's query engine to them. With Snowflake as the catalog you get full read and write support and Snowflake runs maintenance such as compaction. With an external catalog, such as AWS Glue or Snowflake Open Catalog, support is more limited and Snowflake takes on no lifecycle management.

Databricks goes the other way. Its native format is Delta, and Delta UniForm generates Iceberg metadata beside the Delta metadata so 1 copy of the Parquet files serves both. Iceberg access is read-only, the table must be registered in Unity Catalog, and Iceberg reads need Databricks Runtime 14.3 LTS or above. Unity Catalog is also available as an open-source implementation.

If keeping your data readable by several engines is a requirement, write down which engine writes each table and which only reads, then check that against each vendor's documentation for your catalog. For the formats themselves, see Iceberg vs Delta Lake.

Snowpark gives Snowflake Java, Python and Scala libraries built on a lazy DataFrame: building a DataFrame fetches nothing, and an action such as collect sends the generated SQL to Snowflake. The computation runs inside Snowflake, with no separate cluster to manage. It feels like Spark, though it is not Spark, so Spark-specific tuning knowledge does not transfer.

On Databricks, PySpark and Spark SQL run on Spark itself, so partitioning, shuffles, skew and joins are your tuning surface, and Spark knowledge from any other platform applies directly. If your pipelines are Spark jobs today, or your interviews ask about Spark internals, practice with PySpark interview questions and PySpark practice problems.

For SQL-first analytics the 2 feel closer: both take standard analytical SQL, and the window functions, joins and aggregations you write move between them with small dialect changes.

A pipeline design question is rarely about the platform. The same questions apply on either one: where raw data lands, what the grain of each table is, how late data and reruns are handled, and where quality checks sit. A load that is safe to rerun is safe on both, and a pipeline with no freshness or volume check is exposed on both.

What differs is the operating model. On Snowflake you size warehouses, set auto-suspend and decide which warehouse serves which team, so cost control is mostly about warehouse discipline. On Databricks you also choose between serverless and classic compute and between notebooks, jobs and SQL warehouses, so cost control includes cluster configuration. Practise the platform-neutral part with data pipeline interview questions and data pipeline practice problems.

Snowflake fits when most consumers are analysts and BI tools querying in SQL, when a small platform team should not manage clusters, and when the main cost question is how long warehouses run. Its billing is easy to attribute to a warehouse, and a team that sizes warehouses carefully gets predictable behaviour.

Databricks fits when the work is heavy transformation in Spark, when data scientists and engineers share notebooks, when streaming and machine learning sit in the same platform as the tables, or when a policy requires data to stay in open files in your own storage account.

Both fit when a company has an analytics team that lives in SQL and a platform team that lives in Spark, and the open-format features above let them share tables. Neither choice is permanent: the SQL, modeling and pipeline skills you build carry across, and the platform-specific part is a few weeks of learning.

Interviewers use these platforms to test the concepts under them: why compute is separate from storage, how you would size and cost a workload, how you would design a table for the query pattern, and how you would make a load idempotent. Expect to explain tradeoffs in the terms of the company's own stack.

For platform-specific preparation, work through the Databricks interview questions, see how the 2 compare in a loop in Snowflake vs Databricks for interviews, and follow the full data engineer interview prep plan.