by Trent Foley
Much of my work at evolv starts after a company has decided to leave a platform. Sometimes the database is reaching end of support. Sometimes an outside vendor runs the warehouse and the company has no direct control over it. Sometimes the renewal quote just doubled. After 25 years building software and data platforms, I’ve learned that the cost of leaving is set years earlier, on the day the platform was chosen.
In almost every one of those migrations, moving the data is the easy part. Copying the tables is quick. Rebuilding the logic around them is a 16-week program, and until it’s finished the utility runs two platforms side by side, with duplicate tooling, duplicate skills and duplicate cost.
Automated conversion handled about 84% of the objects. The remaining 16% is where the engineering time goes. And a private credit firm we support couldn’t migrate at all in the usual sense. Its warehouse was run by an outside vendor, so a full rebuild was the only path.
None of these companies chose lock-in. They chose a reasonable platform, and lock-in built up around it one stored procedure, one proprietary job and one custom permission at a time.
Know which decisions are permanent
Teams that stay flexible build for interoperability. They know which decisions are permanent and which aren’t. Query engines change every few years, and AI models every few months. The format your data is stored in and the catalog that governs it can last a decade. So make those two choices open from the start and treat everything built on top as replaceable. In practice, staying portable comes down to two open standards: an open table format like Apache Iceberg and an open catalog that lets any engine read and write.
The Hadoop market showed what happens otherwise. In 2019, Cloudera and Hortonworks merged and MapR nearly shut down before HPE bought its assets. Companies that had bet on one vendor’s distribution scrambled. Companies whose data sat in open formats on cloud storage had options.
What lock-in costs
Lock-in shows up on the balance sheet in three ways.
- Exit costs compound. The price of leaving goes up every year you stay. Every report, pipeline and access rule built on a proprietary feature adds to the bill. The gas utility’s 65,000 lines of code didn’t appear in a single year.
- You lose leverage at renewal. If you can’t credibly leave, your vendor knows it. After Broadcom acquired VMware, customers reported price increases of several times what they had paid, and AT&T went to court over it. Oracle’s 2023 switch to per-employee Java pricing hit companies that barely used Java.
- Innovation slows. Teams stop asking “what’s the best tool?” and start asking “what does our platform support?” That is how many analytics teams stayed on SAS while Python took over data science. When trying a new model or engine means exporting, converting and staging a copy first, a two-day experiment becomes a two-week project, and usually it doesn’t happen. That cost never appears on an invoice. It shows up as lost time to value.
Governance is no reason to accept lock-in
Governance used to exist only inside a single database, so strong control and a single vendor went together. Today governance lives in the catalog, and the catalog’s rules apply to every request, whichever engine makes it. Banking solved this decades ago. Your debit card works at almost any ATM in the world, on networks your bank doesn’t own, and it is still one of the most tightly controlled transactions you make. Interoperability and strong control have coexisted there for 40 years. Your bank plays the catalog: it holds the account and sets the rules. The ATM plays the query engine, and it can belong to anyone. Every withdrawal asks your bank for approval in the moment, so your limits and fraud checks apply at any machine, and the machine never holds your balance or a standing key to your account. Governance should follow your data, not your vendor.
Why it matters most in large enterprises
Large enterprises rarely run one platform. Different groups have different skills, and every acquisition brings its own stack.
Several of our larger clients run Snowflake alongside other engines, Databricks included, for streaming and machine learning workloads. None of them can afford a catalog that only works for one engine. For a data and AI leader, owning your data no longer means owning servers. It means having the freedom to change your mind, and to use whichever model, engine or cloud turns out to be best next year without asking a vendor’s permission.
How the major catalogs handle interoperability
Apache Iceberg kept its promise: one copy of your data in your own cloud storage, readable by any engine that speaks Iceberg, at a low cost to switch. The industry has settled on it, Databricks and Snowflake included. The open question has moved up a layer, to the catalog. The catalog holds the pointer to each table’s current version, and every change has to be committed through it, so it decides who can change the table.
Open formats don’t have to cost you performance, either. When our team load-tested 38 million records for an insurer, Iceberg tables loaded in the same 30 to 35 minutes as standard Snowflake tables.
Unity Catalog: open for the tables it owns
Databricks supports Iceberg, and Unity Catalog exposes the standard Iceberg REST API, so outside engines can read and write the tables Unity Catalog governs. The limit shows up in the other direction. When another catalog governs a table, such as AWS Glue or Snowflake Horizon, Databricks reaches it through federation and can read it but not write to it. If a data science team wants to write model scores back to that table, the usual workaround is to copy the table into Databricks. Then there are two copies, two sets of access rules and a sync job someone owns forever.
We’ve seen this pattern before. In the Hadoop era the data sat in open file formats, but the Hive metastore, the catalog of its day, is what made those platforms hard to leave. The Parquet and ORC files were readable by anything, but the table definitions, partitions and access rules lived in a metastore wired into one distribution. Tools outside that stack couldn’t use it, so teams copied data out to warehouses for reporting, and leaving meant rebuilding every table definition and permission by hand.
Federation also changes the security model. To read a table governed by another catalog, an administrator sets up a standing storage permission ahead of time, which gives Databricks standing access to that storage. Plenty of teams manage standing credentials safely, but each one is something a security team has to track, rotate and explain to an auditor.
Open source and open governance are different things, too. Open-source Unity Catalog and the Unity Catalog inside Databricks are different products. The open-source project sits at the Sandbox stage of the Linux Foundation’s AI & Data Foundation, the earliest stage, and Databricks is the only company offering Unity Catalog as a managed service. Single-vendor projects have changed their terms before. Elastic in 2021, HashiCorp’s Terraform in 2023 and Redis in 2024 all moved to more restrictive licenses, and each time a fork followed to keep the code open. The question for a buyer is who controls where the project goes next.
What if I am already running Unity Catalog and hit the federation write wall or my security team simply says no to a long-standing credential and I decide to switch out my catalog? Leaving Unity Catalog doesn’t require moving data. You register each table with the new catalog. What has to be rebuilt is everything Unity Catalog holds around the data: access rules, row and column masking policies, lineage and, for managed tables, file maintenance. And because no other vendor offers a managed version of open-source Unity Catalog, there’s no ready place to land that metadata.
Snowflake: open in both directions
Snowflake’s original idea in 2012 was to separate storage from compute so neither could trap the other. Interoperability extends that idea by separating your data from any single engine, and Snowflake has rebuilt layer by layer to do it. The table format is Apache Iceberg. Apache Polaris is the open vendor-neutral catalog for Apache Iceberg. Horizon Catalog is Snowflake’s built-in catalog, that implements the open Apache Iceberg REST Catalog and Apache Polaris™ APIs natively in every Snowflake account. Any engine implementing the open Iceberg REST specification, such as Spark, Flink and Trino can read and write Snowflake-managed Iceberg tables, generally available since Spring 2026, and Snowflake can read and write Iceberg tables governed by AWS Glue, Apache Polaris or Unity Catalog. .
I asked Prasanna Krishnan, product leader at Snowflake, why a company that made money on its engine would spend so much engineering effort making itself easier to leave. “We wanted to do what is best for our customers for the long term. Our customers were telling us what they needed,” she said. “They wanted their data in a vendor-neutral open format, and have multiple engines work on a single source of truth of data without copying it, while still ensuring governance. They wanted interoperability and open standards at every layer, to avoid lock-in. If we wanted to be in that picture for the long term, we couldn’t be the place their data got stuck. We had to be the place they chose to run their work, every day, because it ran best on Snowflake.”
“Open formats and an open catalog widen the ecosystem for everyone, and that includes us,” Krishnan said. “When your data is in Iceberg and governed through an open source catalog, the bar for us goes up. We have to win on performance, cost, governance and how easy we are to use, not on how hard we are to leave. That’s how we earn customers’ trust and why so many businesses choose Snowflake to begin with.”
Working in both directions is what makes a standard useful. Email works because you can send to and receive from anyone, whatever provider they use. Imagine Gmail that could read Outlook mail but never reply. That is the gap in Unity Catalog’s federation: Databricks can read a table that Glue or Horizon manages, but it can’t write back to it. Snowflake works both ways, reading and writing tables in other catalogs and letting other engines write to its own.
Access is granted one request at a time. When an outside engine asks for Snowflake-managed Iceberg data, Snowflake issues a short-lived credential that covers only that table and logs the access in the catalog. It works like a hotel keycard that expires at checkout: if a guest loses one it stops working on its own and nobody rekeys the building. Remove a permission and access stops when the pass expires, and outside engines are not granted stored storage keys that require rotation.
Governance of the project matters as much as the code. Snowflake donated Polaris to the Apache Software Foundation, where it became a top-level project in February 2026, so Snowflake can no longer change its license or set its roadmap on its own. Google did the same with Kubernetes in 2015, which is a big reason even its competitors run it. If you’re betting ten years on a catalog, bet on one governed by a committee of several companies.
Switching catalogs without moving data
Switching Iceberg catalogs works like moving your website’s domain to a new DNS provider. The website doesn’t move; you change who answers when someone asks where it lives. For each table you register its current metadata with the new catalog, and the data files stay where they are. The real work is recreating permissions. Because both Snowflake and Dremio offer Polaris as a managed service, and you can run the open-source version yourself, you have somewhere to land, and that work typically takes weeks, not years.
Snowflake has fine print too. Tables protected by row-level or column-level policies follow specific supported write patterns from outside engines, so design for them up front.
Interoperability starts at the format layer
Openness comes from the format, the catalog, and the ecosystem, not from where the data is stored. Storage ownership isn’t the issue. What matters is what’s in storage and whether you have full, unrestricted access to it.
When customers ask me whether their data is open, I start with a simple test: can any engine read and write it, and what does the full workload cost to run? Where the files physically sit tells you very little. Data in Snowflake Storage is standard Apache Iceberg, so any engine that follows the Iceberg spec can read and write it. That includes open-source Spark, with no Snowflake or Databricks client software in the path.
The real constraint usually shows up one layer up, in the catalog. Unity Catalog doesn’t use the Iceberg REST Catalog API to reach tables that other catalogs manage, and when it federates to them, it can only read. A format can be open while the catalog in front of it only works in one direction, and that’s where teams get stuck.
The same logic applies to cost. On Snowflake Storage, you pay for active table data not for orphaned files or for cleaning them up. Lifecycle maintenance, including compaction, runs automatically on Snowflake-managed Iceberg tables, including tables in your own bucket, and you don’t need a higher plan to turn it on. On Databricks, Predictive Optimization covers only Unity Catalog managed tables, requires the Premium plan or above, and runs on serverless compute that’s billed separately. The fair comparison is total cost for the same workload, not a single maintenance line item.
Put together, the lesson is straightforward. If openness, maintenance, and cleanup all depend on one vendor’s catalog being the only writer, the data is open in name only. When the format and the catalog follow open standards in both directions, where the bytes sit becomes a cost and operations decision, not a lock-in decision.
The question to ask before you choose
Before you pick a catalog, ask what it takes to leave. Can it write to tables it doesn’t own? Do outside engines get short-lived or standing credentials? Who governs the project? Where would its metadata go if you had to move? Snowflake now offers a standards-based catalog you can move onto and off of, in both directions. Unity Catalog follows the standard for the tables it owns but stops at the ones it doesn’t. For a decision you’ll live with for ten years, that difference matters more than the feature list.
evolv is proud to be an Elite Snowflake Services Partner. Need help with your catalog? Reach out to evolv today.
Trent Foley is the Chief Technology Officer at evolv. His career is built around a single standard: excellence, in the craft and in the client outcome. A well-rounded technologist spanning enterprise applications, cloud, and data, Trent brings more than 20 years of technology leadership, including a decade at ORIX building the platforms behind portfolio management operations and consulting leadership at Slalom. Across engagements in banking, healthcare, and financial services, his measure of success has stayed constant: business value the customer can count. Trent is one of the earliest Snowflake CoCo Champions and a frequent presenter on agentic development at Snowflake events across the country.
