Five years ago the Snowflake-versus-Databricks decision was easy to frame: SQL warehouse for analysts on one side, Spark notebooks for data scientists on the other. Each has spent the years since building the other's product. Snowflake has Snowpark, Cortex AI, Streamlit, Native Apps, Iceberg tables, and a managed Postgres. Databricks has serverless SQL warehouses, Unity Catalog, Lakeflow, and a much better BI story than it had. The feature-comparison spreadsheet is now mostly ticks in both columns.
We are a Snowflake consultancy, so read this with that in mind. But we would rather you chose well than chose us, and the honest version of this comparison is more useful than the partisan one.
Iceberg changed the stakes
The biggest shift is that the choice is far less permanent than it was. Both platforms read and write Apache Iceberg tables in your own cloud storage, and both run (or interoperate with) open catalogs — Snowflake Open Catalog on Apache Polaris, Databricks Unity Catalog with its Iceberg REST endpoint. Put your raw and shared layers on Iceberg and either engine can query them. You are choosing a primary compute and governance engine, not a place to be locked into.
That lowers the cost of being wrong, which should lower the temperature of the decision.
Decide on workload mix
Where the platforms still differ is in what they are best at, and that maps to your workload mix:
- Mostly SQL analytics, BI, and ELT. Snowflake's warehouse model — pick a size, it just runs, suspend when idle — is still the simpler operational experience, and its SQL engine, Dynamic Tables, and dbt Projects on Snowflake make a SQL-first data team very productive. Databricks SQL is now competitive on performance, but the platform's centre of gravity remains Spark and the notebook.
- Heavy Python / Spark data engineering and ML training at scale. Databricks is built around this. Snowpark closes a lot of the gap for Python transformation and Snowpark Container Services handles custom ML serving, but if your team lives in PySpark and trains large models daily, Databricks will feel more native.
- LLM and GenAI on governed enterprise data. Snowflake's Cortex (AISQL functions, Cortex Analyst, Cortex Search, Snowflake Intelligence) is remarkably quick to put to work because it is just SQL over governed tables. Databricks' Mosaic AI is more flexible and more code-centric. Which is better depends on whether your AI team is analysts or ML engineers.
- Streaming. Both are credible: Snowpipe Streaming and Openflow on one side, Structured Streaming and Lakeflow on the other. Databricks has the deeper streaming-processing toolkit; Snowflake has the simpler streaming-ingest-to-query path.
Decide on team skills
This is the factor most often underweighted. A platform your team already knows will outperform a marginally better platform they are learning. Snowflake rewards SQL depth and a data-warehousing mindset; Databricks rewards software-engineering practices and Python fluency. Look at who you have and who you can hire in your market before looking at benchmarks.
Decide on governance
Snowflake Horizon (RBAC, tags, masking and row-access policies, data sharing, the Marketplace) and Databricks Unity Catalog are both mature. The practical differences: Snowflake's governance is uniform because everything is a Snowflake object; Unity Catalog has to govern a broader surface (files, notebooks, models, clusters), which is more powerful and more to configure. Data sharing across organisations is still a Snowflake strength, particularly where the counterparties are also on Snowflake.
Cost
Neither is cheap, and both bill on consumption, so the real cost is a function of how well the platform is run. Snowflake's per-second warehouse billing and aggressive auto-suspend make it easy to control once someone owns it (see our cost optimization service). Databricks' cost profile depends heavily on cluster policies and whether you use serverless. In practice the platform with an engaged cost owner wins on price, whichever it is.
How to choose anyway
- Write down your actual workload mix for the next two years, in percentages.
- Write down your team's skills honestly.
- Put shared and raw data on Iceberg from day one so the decision is reversible.
- Pick the platform that is native for the largest slice of the first list and the strongest fit for the second.
- Run a four-week proof of concept on your real data, with your real team, measuring cost and time-to-delivery, not feature checkboxes.
If the answer is Snowflake — or if you are on Snowflake and want it run well — talk to us. If the answer is Databricks, choose it with a clear conscience; the data will still be portable either way.