We move data estates onto Databricks for a living, so the following is against interest. The best reason people used to give for leaving Snowflake stopped being true this year.
The argument went like this. Your data sits in a proprietary format inside somebody else's warehouse, only their engine can read it, and every year you stay the exit gets more expensive. Move to an open format now, while the bill is still survivable.
It was a good argument. It's now mostly wrong, and knowing why changes what a sensible migration decision looks like.
What actually changed
In March, Snowflake shipped write support for its Iceberg tables from any external query engine that speaks the Iceberg REST protocol. Horizon Catalog integrates Apache Polaris and is REST-catalog compliant, and a Snowflake account can connect to an external catalog, including Unity Catalog, through a catalog integration.
Databricks moved the same distance from the other side. In May, Managed Iceberg went generally available in Unity Catalog, along with Iceberg v3 and Foreign Iceberg. Any engine can create, read and write Unity Catalog Iceberg tables through the REST Catalog APIs, and the engines Databricks names include Spark, Trino, Flink, DuckDB, pandas and Snowflake.
Read those two paragraphs together. Both vendors now publish an open catalog interface, both can read the other's tables, and the storage format underneath is the same open specification. The wall people were trying to escape has a door in it, and both parties fitted the handle.
That is a genuinely good outcome, and it deserves saying plainly even though it removes a line from our sales conversation.
What the wall became
None of this means the two platforms are interchangeable. It means the difference moved.
Format was the old lock-in. The catalog is the new one, and interoperability at the catalog layer is thinner than the announcements suggest. There's common open storage across Iceberg and Delta, and there's no equivalent open parity between catalogs. Each vendor competes on exactly that layer, because it is what remains to compete on.
You can see the gap in practice. Writing to the other platform's tables often works, and the people who are frustrated are usually the ones who tried a specific bidirectional path and found the documentation confident but thin. The capability is real and the edges are sharp, which is a normal place for a standard to be eighteen months in.
So the honest version of the old argument is smaller and more precise. You aren't trapped by your table format any more. You are choosing which catalog holds your grants, your lineage and your governance, and that choice is still hard to reverse.
Then why do teams still move?
Three reasons hold up when you look at what people actually did, and none of them is the format.
The workload stopped being SQL. Snowflake is very good at what it was built for, and its compute model shows it. You pay per second with a sixty-second minimum when a warehouse wakes, auto-suspend is on by default, and a warehouse that is not running costs nothing. For spiky analytical SQL that model is close to ideal. It fits less well when the work becomes long-running transformation, Spark jobs and model training that hold compute for hours, because the thing that made short queries cheap doesn't help you there.
The data has to reach an application. A warehouse answers questions. Somewhere past a certain point, the interesting work stops being a dashboard and becomes software: an operator console, an agent with permissions, a service that writes back. That is where a lakehouse with an operational database next to it does something a warehouse was never meant to do, and it's the part pure data teams underestimate because building the application is a different discipline from building the pipeline.
Two platforms, two bills, one dataset. A surprising number of estates end up running Snowflake for analytics and Databricks for engineering and ML, then paying to keep them in step. Consolidation is a real driver, and it is worth noting it points in whichever direction the larger workload already sits. Sometimes that answer is Snowflake, and we have said so.
When you should stay
If your workload is SQL analytics and business intelligence, your users write SQL, and your bill is predictable, then Snowflake is an excellent product and a migration is a large amount of work to arrive somewhere similar. Stay.
If your team is SQL-first with no Spark experience and no plan to hire it, moving the platform moves the problem into a skill set you don't have. The migration is the easy part. Operating what you land on is the rest of your life.
And if the driver you have been given is that your data is trapped, ask which specific workload can't read it today. Since March that question has a real answer more often than not, and if nobody can name the workload, the argument is a habit rather than a reason.
What a good decision looks like now
The decision got narrower and more technical, which is an improvement. It's no longer a stance about openness. It's an inventory question.
Name the workloads. Separate the SQL that serves dashboards from the transformation that runs for hours from the training jobs from the applications you want to build next. Cost each one where it currently runs. Then ask which platform each would sit on if you were starting today, and whether the split is worth two bills.
That exercise usually decides itself, and it decides against a migration more often than a migration vendor's blog will tell you. When it decides the other way, the reasons are specific and you can defend them to a board, which is what makes the project survivable when it gets hard in month four.
Our Snowflake readiness sprint is two weeks and does exactly that inventory. Scope written down, exclusions agreed, and a wave plan. If the finding is that you should keep the warehouse where it is, that is a finding, and we would rather deliver it in two weeks than six months in.
Sources
Checked on 7 September 2026:
- Write support for externally managed Apache Iceberg tables and the March 2026 release note covering external query engine writes
- Configure a catalog integration, Snowflake
- Unity Catalog and the next era of Apache Iceberg, Databricks, 28 May 2026
- Understanding compute cost and cost controls for warehouses, Snowflake