Lock-in is a price, not a sin

Lock-in discussions run on fear, and fear prices everything the same. The useful question is never "are we locked in" (you are, somewhere) but "at which layer, at what exit cost, in exchange for what". Priced layer by layer, the picture usually surprises people.

Storage and formats: cheapest to keep open. Open table formats made this layer genuinely portable; engines increasingly read each other's tables, and interop layers write one table readable as several. Keeping storage open costs little and preserves the most options. Take the free option. Free at the format layer, that is: operating open tables is a standing job, and five questions decide whether your team is ready for it.

Compute: moderately sticky, honestly rented. SQL mostly ports; performance tuning, workload management and pricing models do not. Exit is a project, not a crisis. Renting excellence here is usually a good trade, which is why the warehouse remains the right product for many teams.

Catalog and governance: the quiet stickiest layer. Access policies, lineage, audit history and every tool integration accumulate here. The catalog interface question is where 2026's real lock-in decisions live: a REST-spec catalog keeps the exit priced in months, a proprietary one prices it in years. When you adopt one, buy it for the access problem and on the open interface, so the stickiness stays a choice.

Proprietary SQL extensions and platform-only features: the trap layer. Each one saves a sprint now and adds a quarter to the exit. Use them consciously, inventoried, or not at all.

How to build the inventory without a quarter of archaeology. The proprietary-dependency list compiles itself from three queries: scan the transformation codebase for platform-specific functions and syntax, list the scheduled jobs that call platform-only services, and pull the feature flags enabled on the account from the vendor's own console. Two days of work for a mid-sized estate. Each entry gets a replacement note, one line: what the open equivalent would be, and roughly how long the swap would take. The total at the bottom of that page is your exit cost, and it is almost always dominated by five entries, which tells you exactly where to stop adding platform-only cleverness.

Reprice it annually. Exit costs drift in both directions: open equivalents mature and get cheaper to adopt, while every year of platform-specific development adds entries to the list. An inventory from two years ago is a historical document. We schedule the repricing with the budget cycle, so the number walks into the renewal conversation the same week the vendor's pricing does.

One caution against overcorrecting: a platform built to be maximally exit-ready everywhere pays the multi-vendor tax daily for an event that may never come, in glue code, in weaker support, in features declined on principle. Lock-in is not a sin to eliminate; it is a price to know. Some layers are worth paying it at, and the inventory exists so that sentence can be defended with numbers rather than mood.

The posture we recommend in assessments: open where it is cheap (storage, formats, catalog interface), rented where it is excellent (compute, optimization), and a written inventory of every proprietary dependency, so the exit cost is a number on a page instead of a discovery during a renewal negotiation. Renewal negotiations go differently when both sides know you can leave.

The inventory has one more audience worth naming: your own future architects. Half the trap-layer dependencies we find were adopted by people who left years ago, for reasons nobody recorded. A dated entry with a rationale turns tomorrow's archaeology into a reading assignment, and that alone repays the two days it costs to compile.