Zeotap's composable CDP is live on the Snowflake Marketplace, running inside your own Snowflake account as a Native App. That is the announcement, and it is the boring half.
The half I care about came from Jonaten Kraus at Snowflake, who spent about six months on this before it shipped and then wrote up what really happened on LinkedIn. His framing is the whole thing. Snowflake wasn't deciding whether to approve another marketplace app. It was deciding whether to treat Zeotap as a partner instead of a customer.
Snowflake picked a category vendor and pulled it deeper into the platform on purpose.
Read the Zeotap blog, and you see a product launch.
Read Jonatan, and you see recruitment or, at a minimum, a pursued collaboration.
What Zeotap actually shipped
The product is a composable CDP, live on the Marketplace, built as a Native App on Snowpark Container Services.
Here is the claim that matters.
Zeotap says the whole thing runs as a container inside your own Snowflake account, not on Zeotap's servers reaching in from outside.
That is a big claim, and the kind I don't take on a vendor's word, so I went and looked at the architecture instead of the press release. It holds up. Identity resolution and journey logic run in your Snowflake, on your compute, with Zeotap out of the data path.
Most tools that say they run "on Snowflake" still do the real work on their own servers. This one runs the whole thing in your account.
Only one of the four moved in
"On Snowflake" turns out to cover a lot of ground, and these four are spread right across it.
RudderStack shows up on Snowflake in more than one form. Its reverse-ETL and event-stream pipelines are the old-fashioned kind, moving data in and out with credentials while the platform stays on RudderStack. Its Profiles product goes further and runs identity resolution warehouse-native, building the identity graph and customer tables as models inside your Snowflake. So a piece of RudderStack does run in your account. The rest of it doesn't.
Hightouch splits the same way. The activation engine most people know reads from Snowflake at sync time and pushes data out to your tools, and that runs on Hightouch's own servers. Its newer AI Decisioning is delivered as a Snowflake Native App and leans on Snowflake Cortex to work inside your account, with the activation still handled by Hightouch. So a slice runs in your warehouse and the rest stays home.
Amperity keeps its distance on purpose. Its Bridge integration uses zero-copy sharing, so your data never gets copied into a second home, which is the thing most buyers actually lose sleep over. Your data stays put. The compute doesn't. Amperity's identity resolution still runs on Amperity.
Then Zeotap, which moved the whole thing in. It runs the entire composable CDP as a container in your Snowflake account through Snowpark Container Services, with identity resolution and journey logic executing on your compute and Zeotap out of the data path.
A slice of the others runs in your warehouse. Zeotap is the only one, for now, that packed up the whole operation and set it down inside yours. Whether you want a tenant that deep in your account is a separate question, and a fair one.
Databricks did this first, in the other well
If this feels familiar, it is because I wrote most of it a month ago about Databricks.
Two gravity wells, Databricks and Snowflake, both pulling the CDP toward wherever your data already lives. Jonaten said it with "Where will customers be? Where can we create the most value?", or simply put:
Whoever hosts the CDP without the data leaving keeps the account.
Databricks built its own. CustomerLake is a CDP it stood up inside the lakehouse, staffed with the people who used to build the independent CDPs it is now swallowing whole.
From what we can now see, Snowflake got to the same place, but from the other side. Instead of building a CDP, it recruited one and helped it move in.
Same destination. The only real difference is whether the platform builds the front door itself or hands a vendor the keys and the blueprints.
Matthew Niederberger
Read my thoughts on Databricks' CustomerLake announcement ☝️
Snowflake recruited it
This is why Jonaten's post beats the Zeotap blog. It is the platform telling you it influenced the whole thing.
Zeotap started out built mostly on GCP and BigQuery. The Snowflake connector was an afterthought. Then, by Jonaten's account, the conversation turned strategic, and not in the features-and-pricing sense. It was about where Snowflake's customers were going to sit, and how to build an ecosystem where a partner could grow instead of ending up in a fight with the platform it runs on.
The plan was composable CDP first, Native App second. Zeotap's team, Sathish, Pritika and Aniket, shipped both in about six months. 😳
As a build, that is fast. That should not a surprise in this day and age of agentic coding, so bare with me when I say that it is the strategy underneath is the part worth watching. Snowflake went looking, for reasons that can only be speculated about. It got into a vendor's roadmap and pointed it deeper into Snowflake. To be fair, Databricks did pretty much the same dance when it pulled the customer-engagement crowd into CustomerLake's orbit.
The bill lands on you now
Don't go into this bind, because here is a consequence that is easy to miss.
When the CDP runs inside your account, on your compute, the cost of running it shows up on your Snowflake bill, not on a Zeotap invoice.
Zeotap calls that transparency, and fair enough, there is a real version of that argument. You see what the thing actually costs instead of a flat fee that buries it.
It cuts the other way too. As all things SaaS do.
A CDP that shows up as Snowflake consumption is a CDP that is much harder to line up against its rivals on price, and every dollar it burns feeds Snowflake's own consumption growth.
Keep that in view before you take the transparency framing at face value.
So I asked Zeotap
The biggest claim in the whole launch is the security one:
The vendor never touches your data.
For a regulated buyer that is not nothing. And underneath it sits the question none of the blogs answer, whether "runs inside your account" means Zeotap rebuilt its identity resolution and journey logic for Snowpark Container Services, or wrapped the existing thing in a container and shipped it somewhere new.
So I put it to Aniket Awati, Zeotap's Vice President of Engineering. His answer was more specific than I expected, and the story starts before the native app.
Zeotap re-architected for composable early last year, pushing the heavy compute down into the customer's warehouse instead of copying data into its own cloud. By the time the native app came along, the CDP core already ran as pushdown SQL in Snowflake: the identity engine, the journey engine, the compilers. So the native app didn't move the query compute. That had already moved. What it moved, in Aniket's words, was the rest.
We moved the entire control plane in-account
Job execution, secrets, the event bus, the metadata store, all re-plumbed to run inside Snowflake through Snowpark Container Services, with the CDP logic carried over intact.
So the honest answer to my own question is a third thing. The hard part, moving the compute, happened in the composable rebuild a year ago. The native app moved the control plane in to sit beside it. That makes the "runs inside your account" claim sturdier than I could confirm from the outside.
On the security line, Aniket's answer was the strongest of the lot. Every outbound path is enumerated and approved, first by Snowflake's own app review, then by the customer through the access grants they control. "There is no undocumented outbound route" he told me. That is a real assurance, and easier to give from inside the account than from outside it. Whether it swings an enterprise deal is still the open question. The mechanism isn't in doubt. Whether buyers actually optimize for it is.
On cost I stay a shade more skeptical, though he had a fair answer there too. Aniket reframes the "invisible on a vendor comparison" worry as transparency:
The fee becomes the price of Zeotap's IP, and the infrastructure runs as Snowflake consumption the customer can see and size for themselves.
He even grants the split "isn't a fully solved problem". His answer covers visibility for the customer. It doesn't touch the other half I flagged, that the same move feeds Snowflake's own consumption number.
Both are true at once, and only one of them was the question.
So what do you do with this
If you have a CDP decision open right now, do the boring thing first and look at your whole martech stack before you fall for any one piece of it.
That is the reason I built Martech Stack Builder.
The part I can't get past sits above any martech stack diagram. When the platform gets to decide which vendors get promoted from customer to partner, and helps rewrite their roadmap on the way, how independent is the CDP that took the deal?
Do you have any questions after reading this article?
Or need support with your Martech projects?
A note on sourcing: this piece is built from publicly available information, the vendors' own documentation and announcements, Snowflake's, and one on-the-record interview with Zeotap. If I have a detail wrong about how any of these products runs, tell me and I'll correct it.
Discussion