August 2026 · 7 min read · Part 2 · Stop Picking a Winner
The seam is the risk
Both platforms are staying, so the decisions that matter are the boundary between them and the run rate underneath. What is actually portable, why the second transformation layer is the trap, and why the committed fee is a floor rather than a ceiling.
The last post translated the vocabulary and landed on a narrow question: whether Foundry’s assembled action layer is worth its contract. This one is about everything that follows from answering yes. Both platforms stay. So what is portable, where does the boundary go, and what does the second platform do to your run rate.
The same disclosure as last time. I do not have a side here and I am not selling either platform. The cost section below is the part most likely to read as an argument against one of them, which is exactly why it is worth repeating.
Closed versus open, honestly
Nobody here is open. There are degrees.
On the Snowflake side, the data in Iceberg is portable, the SQL is portable, the dbt project is portable. The Cortex configuration, the semantic views, the Snowpark code, the tasks and streams are not. That is a real dependency and a survivable one, because the part that took the longest, the modeled entities, leaves with you.
On the Foundry side, more of the data layer is portable than the reputation suggests. Transformed data sits in open formats and comes back out. The ontology does not. Neither do the actions, the Workshop apps, or the AIP logic, and there is no open ontology standard to export to. So the lock-in is real and it is not where people look for it. It is in the layer you would most want to keep.
Write the rule down before anyone builds anything. Physical data and transformation logic stay in open, portable form. Accept lock-in only where you are buying a runtime you would not build yourself. A governed action layer is plausibly worth being locked into. A second copy of your revenue model is not.
And the exit question is not “can we leave.” It is “if we switched this off in the next 18 months, what would we have to rebuild, and how long would it take.” Answer that in writing now, while nobody is emotional about it.
Pick the boundary before the first pipeline
Foundry will read from Snowflake through virtual tables, connector syncs, or Iceberg, and it will write back. Mechanically that is not the hard part.
The trap is the second transformation layer. Someone syncs raw tables into Foundry because it is faster than waiting on your dbt backlog. They build the joins there. Now “active customer” exists in two places, with two owners and two release cadences, and six months later they disagree and nobody can say which one is wrong. I have written before about what happens when two planes hold the same definition and drift apart. This is that failure on a shorter fuse, because Foundry’s build tools are good enough that the shortcut works.
So set the boundary and give it an owner.
- Snowflake is the system of record and the transformation plane. Entities are defined once, in dbt, in SQL you can read.
- Foundry consumes governed marts, not raw tables. If a use case needs something that does not exist yet, it goes in the dbt backlog and gets built once.
- The ontology adds what Snowflake does not have: links, object state, and actions. It does not re-derive what Snowflake already computed.
- Writes from actions land back in the operational system and in Snowflake, and Snowflake keeps the record.
That boundary will get violated. The question is whether anyone is watching for it, so name the person.
Cost is a different shape, not a different number
The finance conversation goes sideways because someone frames it as commitment versus consumption. That framing is wrong in the direction that costs you money.
Snowflake is consumption. Marginal, visible, attributable per query and per warehouse, and tunable. A bad query has a price and the price shows up next month.
Palantir is a committed platform fee sitting on top of consumption, and the consumption does not disappear because the fee is large. Count three meters. The contract is negotiated, front-loaded, multi-year, and by Palantir’s own account the pricing is generally fixed, though the same disclosure allows for variable consideration. The platform meters compute-seconds against vCPU, memory, GPU, and runtime, and AIP meters model calls down to input tokens, output tokens, and cache reads. The infrastructure is the third, folded into the fee when Palantir hosts, landing on your own bill when you run it in your cloud or buy through a marketplace.
So the marginal cost of the next use case runs upward, and the vendor’s own reporting says so. Palantir put net dollar retention at 157% in the second quarter of 2026, up from 139% two quarters earlier, on $352 million of existing-customer expansion the quarter before that. Read that as the average existing customer spending half again what it spent a year ago. A platform where the next use case rides free does not produce that number.
Three things drive the curve. Consumption rises with data volume, pipeline frequency, object count, and the compute behind your transformations. Delivery rises alongside it, because Palantir attaches its own engineers to most new deployments and that labor is priced, not donated. And the contract ratchets at renewal, because expansion is the design of the business rather than a side effect. Your first contract is a floor, not a ceiling.
You will still be told to raise use cases per contract, because the fee is spent whether you use it or not. That is true of the fee and false of everything underneath it. Three apps on a committed platform is a bad outcome, but the fix is not to assume the fourth and fifth are free. Budget the expansion curve, because the vendor already has.
You also pay twice for everything you copy, on more meters than before. The same rows stored in both places, transformed in both places, moved between them, and metered on both sides with the cloud bill underneath. That is tolerable for a governed mart and indefensible for raw history. It is the boundary argument again, in the version finance will engage with.
Then change the meter. Cost per query was the right instrument for a warehouse serving dashboards. It is the wrong one for a platform whose whole claim is that a planner did something different on Tuesday.
The first ninety days
Write the entity contract. One definition of customer, order, SKU, whatever your business actually turns on. Where it lives, who owns it, how a change gets approved. Do this before the first pipeline, because after the first pipeline it stops being a decision and becomes a negotiation.
Pick use cases where the write is the point. If it is a question with an answer, it stays in Snowflake. You already paid for that. Foundry earns its cost where a human takes an action against an object, under a permission, with a record.
Staff it on purpose. The forward-deployed model works, and it is a line item you are buying rather than help you are being given. The failure mode is a parallel team that reports somewhere else and builds against its own definitions. Pair your engineers to theirs on day one and make the pairing a condition, not a courtesy.
Instrument both platforms on the same meter, and write the exit reading down while it is still cheap to be honest about.
The seam
The work you have already done is not sunk. The entity work is the asset, and it was never Snowflake-specific. Whatever the ontology ends up modeling, it models the definitions you already fought for, or it models new ones somebody invented against a deadline.
That fork gets decided in the first month, usually by people who do not know they are deciding it. Most of the risk is not in either platform. It is in the seam between them.