When Databricks and Snowflake Work Better Together, and When They Do Not

A retail analytics team I know spent eleven months building the case to migrate off Snowflake onto Databricks. The case was clean. One platform, one bill, one set of skills to hire for.

They never finished it. Two years later they still run both, alongside the forty-odd sync jobs they built to keep the two sides in agreement while the migration was in flight.

The migration was cancelled. The pipelines it created were not.

Most companies are still arguing about which platform to keep. Almost nobody has priced the argument itself. The copies are what you are actually paying for.

What consolidation actually buys you#

The instinct to pick one is not naive, and it deserves a straight hearing. Two platforms means two contracts, two security reviews, two sets of on-call runbooks, and two hiring markets. Your Spark people and your SQL people stop reading each other's code. Every new data product starts with a twenty minute argument about where it should live.

Those costs are real, and anyone who tells you the answer is obviously "run both" has not sat through the procurement cycle.

But look at what enterprises actually do rather than what the architecture diagrams say. In a joint customer survey of 105 organizations, including 29 from the Fortune 500, theCUBE Research and ETR found that roughly 60% of Databricks accounts also run Snowflake, and roughly 40% of Snowflake accounts also run Databricks. That came out of ETR's quarterly panel of about 1,800 respondents.

The consolidation intentions are weaker than the rhetoric. In the same research, 44% had no plans to change their mix at all. Only 4% were phasing out Snowflake entirely, and only 2% were phasing out Databricks.

The bake-off is loud. The migrations are rare.

The layer nobody owned#

If both platforms are staying, something has to keep them in agreement. That something is almost never designed. It accretes.

It usually starts as one nightly job copying a dimension table so the finance team can join it in Snowflake. Then a second job, because the data science team needs the same table in Databricks with three more columns. Then a reconciliation job, because the two disagreed during a quarter close and nobody could say which one was right.

Nobody owns this layer, which is precisely why it grows. Platform teams own the platforms. Analytics engineering owns the models. The sync jobs between them belong to whoever wrote them, who has usually moved teams.

Ask what the second platform costs and you will get a licence number. Ask what the pipelines between them cost and you will get a pause. That pause is the actual answer.

You are not paying for two platforms. You are paying for two platforms and a third system that has no name, no owner, and no roadmap.

So has interoperability actually arrived, or is this vendor marketing?#

Fair question, and the honest answer requires reading past both vendors' blogs, because both of them are currently describing the other's gaps more enthusiastically than their own.

Here is what is verifiable from the documentation. Apache Polaris, the catalog underneath Snowflake's Horizon, graduated to a top-level Apache project in February 2026. Snowflake's own release notes record that Iceberg write support for Databricks Unity Catalog on Azure went generally available on 6 April 2026. On the other side, Databricks documents read access through the Iceberg REST Catalog API as generally available for managed and external tables, with write supported for both and credential vending available to Iceberg and Delta clients alike.

So the headline claim holds. Both engines can now read and write the same physical Iceberg tables, without either one owning the copy.

What does not hold is the implication that this is finished. It is not, and the gaps are specific rather than vague.

Four decisions worth making before you touch anything#

One architecture diagram will not settle this. Four decisions will, and they are the ones that actually get argued about in review.

1. Who owns the catalog. This is the only one that is genuinely hard to reverse. Governance does not travel between catalogs, because there is no industry standard for exchanging policies. A row-level rule written in Unity Catalog does not appear in Polaris. Pick one catalog as the governance boundary and route every engine through it, or accept that you will maintain the same rule twice and discover the drift during an audit.
2. Where transformation runs. Heavy Spark work, streaming, ML feature generation, and anything that needs Python in the middle belongs where the compute model was built for it. This is the least controversial split and the one teams usually get right by accident.
3. Where the business-facing serving layer lives. Concurrency behaviour under a few hundred simultaneous BI users is a different engineering problem than throughput on a large batch job. Decide this on your actual query mix, measured, not on a vendor benchmark run against someone else's workload.
4. Which tables are shared and which are private. Not everything needs to be readable by both engines. Shared Iceberg tables carry real constraints. Private native tables do not. Being deliberate about the boundary is what keeps the shared set small enough to govern.

Decide those four and most of the remaining questions answer themselves.

The uncomfortable part: it is your pipelines, not your vendors#

Line up the cost of a two-platform estate and the second licence is rarely the line that hurts. The duplication is.

The failure modes are boringly specific, and every one of them is documented rather than theoretical:

• Zero-copy is not zero-egress. Removing the duplicate copy stops you paying twice for the same bytes. It does nothing about bytes crossing a region boundary at query time. Teams that consolidate storage without consolidating regions get the same surprise line item, just under a different name.
• External tables offer no cross-engine transactional guarantee. Databricks states it plainly: reading and writing to external tables from multiple systems "can lead to consistency issues and data corruption because no transactional guarantees are provided for formats other than Delta Lake."
• Direct storage access escapes the catalog. Again from the documentation: Unity Catalog "does not govern reads and writes performed directly against cloud object storage from external systems." The catalog governs the door, not the wall.
• Views do not cross. External Iceberg engines cannot read views defined in Unity Catalog. Logic living in a view stays where it was written.

None of that argues against sharing tables. It argues against assuming the sharing is free.

A two-platform estate is not expensive because you bought two things. It is expensive because you built a third one to connect them.

The math your finance team will actually care about#

Skip the headline saving. Here is the arithmetic, and your own storage and salary numbers drop straight into it.

Approach

The first row is the only one where the cost ends. The second row is where most enterprises are sitting right now, and it is the only one of the three where the bill grows on its own. The third row is not free, but the recurring line is gone.

The choice that matters is not row one versus row three. It is getting out of row two.

Keep the consolidation plan. Just narrow it.#

None of this means the single-platform strategy was wrong. For a company with one analytics workload, one region, and one team, two platforms is an expensive way to have an opinion. Consolidate and do not look back.

What should change is the scope of the ambition. Consolidating the copy is achievable this quarter and pays immediately. Consolidating the vendor is a multi-year programme with a well-documented habit of stalling somewhere in the middle, which is exactly where the pipeline sprawl comes from.

Consolidate the data. Stay flexible about the engines.

How to start on Monday#

You do not need a migration budget or a new vendor to begin.

1. Count the pipelines. List every job whose only purpose is moving data between the two platforms. Not transforming it. Moving it. Most teams guess low by a factor of two, and the real list usually ends the debate on its own.
2. Find the tables written twice. Of those pipelines, identify which tables are genuinely read by both engines. That set is almost always smaller than the set being copied, and it is your shared Iceberg candidate list.
3. Name the governance owner. Decide which catalog is the boundary and who owns it, before you share the first table. Doing this after the fact means unpicking access rules under audit pressure, which is a far worse week.

The point of all this is not architectural purity. It is that the question most teams are asking has already been answered by the market. Both platforms are staying. Snowflake closed FY2026 with 13,328 customers and 790 of the Forbes Global 2000. Databricks reports more than 20,000 organisations and 70% of the Fortune 500. Those customer lists overlap heavily, and neither is shrinking.

The interesting question is no longer which one wins. It is how many copies of your data the disagreement is costing you.

Morpheralabs builds data platforms, cloud infrastructure, and internal tooling for engineering teams. A fair amount of that work involves untangling the pipeline layer that grew between two systems nobody quite decided on. If that sounds familiar, we are happy to talk it through.