The hardest objection in every enterprise build-vs-buy conversation about marketing data is not price. It is custody: your security team does not want marketing data living in a vendor's cloud, and they are right. We recently shipped the architecture that concedes the point instead of arguing with it: extraction that writes Apache Iceberg tables straight into the customer's own S3, where their Snowflake reads the data in place. No copy on our side, no export step. Our storage becomes optional. Once custody is off the table, build versus buy stops being a trust debate and becomes arithmetic, and that arithmetic is what this article, the first in our Build vs. Buy series, walks through.
Key Takeaways
- Zero-copy here means literal: connectors write Apache Iceberg into your own S3 bucket, and your Snowflake reads those tables in place. The data never has to sit in our storage.
- Transformations, dashboards, and the AI agent all run against your warehouse, through a read-only role scoped per workspace.
- We built this with one of the largest advertisers in the country, whose answer to "just trust our cloud" was always going to be no. It is early: today we run it by request.
- With custody solved, the build-vs-buy decision reduces to a build-side sum: connector maintenance across 500+ platforms, governance, and the context layer an agent needs.
- The honest way to run the evaluation is to price both paths over years, not months, and to demand the same security answers from a vendor that you would demand from your own build.
Two Objections That Are Both Right
Enterprise evaluations of marketing data platforms keep producing the same two objections, from two different rooms.
The security team says marketing data should not have to live in a vendor's cloud. They are right. Ad platform data carries spend, audiences, and customer identifiers, and every copy that exists outside your own perimeter is surface area you have to govern, audit, and explain.
The engineering team says they could build the pipelines themselves. They are also right. None of the individual pieces is beyond a competent data team: call the APIs, land the files, model the tables.
Most vendor answers to the first objection are a stack of certifications and a request for trust. The answer we now give is architectural instead: the data does not have to touch us at all.
What Zero-Copy Actually Means Here
The phrase gets used loosely, so here is the concrete version we shipped:
- Extraction writes Apache Iceberg tables directly into your own S3 bucket. Iceberg is an open table format, so what lands in your bucket is queryable open data, not a vendor blob.
- Your Snowflake reads the data in place as external Iceberg tables. There is no nightly copy into a vendor warehouse and no export step back out of one.
- Transformations, dashboards, and the AI agent run on top of your warehouse, connecting through a read-only role scoped per workspace. What we can see is defined by a grant your team controls and can revoke.
- Our own storage layer becomes optional in this design rather than a requirement of it.
We built this with one of the largest advertisers in the country, because their answer to "just trust our cloud" was always going to be no, and they were never going to be argued out of it. That is the right posture for an enterprise security team, and designing for it produced a better architecture than defending against it would have.
Honest status note: this is early. Today we run zero-copy deployments by request rather than as a self-serve default. If your evaluation depends on it, say so at the start of the conversation.
Talk to an expert if you want to walk through the zero-copy architecture against your own security requirements.
The Arithmetic That Remains
With custody off the table, what is left of build versus buy is a sum, and it deserves to be priced honestly rather than emotionally, in either direction.
The build side has three recurring line items:
- Connector maintenance. Marketing runs across hundreds of platforms; we maintain integrations with more than 500 of them. Each one is an API that its platform evolves on its own schedule, with versions, deprecations, and schema changes your pipelines have to absorb. Building five connectors is a project. Keeping dozens alive for years is a team.
- Governance. One naming convention, one definition per metric, access control, and an audit trail. This is the part in-house builds most often defer, and it is the difference between a pipeline and a data foundation. I made the same argument from the agent's side in the trust layer article: intelligence built on an ungoverned layer inherits its disagreements.
- The context layer. If you want an agent to answer questions about your marketing, it needs to know your accounts, your naming, your history. That knowledge layer has to be built and kept current, whoever owns the pipelines.
The buy side has its own line items: the license, the onboarding, and the questions you should force any vendor to answer about custody, access scope, and revocation. I wrote out the credential-custody version of this argument in Build vs Buy Data Integration in the Agent Era; this article is the storage-custody half of the same series.
Run the numbers over years, not months. A build that looks cheaper for a quarter usually looks different once connector maintenance, governance, and the context layer are staffed for year two and three. If your sum genuinely comes out lower in-house, with all three line items priced, you are one of the teams that should build, and I mean that without irony.
Talk to an expert to price both paths against your actual platform mix and warehouse setup.
How to Run the Evaluation
Whichever way you lean, the same checklist keeps the decision honest:
- Ask the vendor where the data physically lives, byte by byte, and what stops working if you deny them storage. A zero-copy answer should name the format and the bucket owner, not a compliance page.
- Ask what the vendor can see and how you revoke it. A read-only role scoped per workspace is a revocable grant your team controls; anything vaguer deserves a follow-up question.
- Price the build with all three line items staffed over three years: connector maintenance, governance, and the context layer.
- Whatever you choose, keep the data in an open format in storage you own. That keeps the decision reversible, which is worth more than either path's pitch deck.
Frequently Asked Questions
What does zero-copy mean in marketing data integration?
It means extracted data is written directly into storage the customer owns, in an open format, and queried there. In our implementation, connectors write Apache Iceberg tables into the customer's S3, and the customer's Snowflake reads them in place. There is no copy held in the vendor's warehouse and no export step.
Does the vendor still see the data?
Transformations, dashboards, and the AI agent connect to the customer's warehouse through a read-only role scoped per workspace. The access is a grant the customer's team controls and can revoke, not a standing copy.
Is zero-copy generally available?
Not yet as a self-serve default. It is early, and today we run zero-copy deployments by request. If your evaluation depends on it, raise it at the start of the conversation.
Does this require Snowflake?
The shipped design targets S3 plus Snowflake reading external Iceberg tables in place. Because Iceberg is an open table format, the data in your bucket stays queryable by other Iceberg-aware engines; the deployment specifics are part of the by-request conversation.
Why would a vendor make its own storage optional?
Because for enterprise security teams, vendor storage is the objection, and no amount of certification argues it away. Making storage optional concedes a point the customer is right about, and it removes the trust question from build versus buy, which leaves the arithmetic we are happy to compete on.
What should we compare when pricing build versus buy?
Three build-side line items over a multi-year horizon: connector maintenance across every platform you use, governance including naming and metric definitions, and the context layer an agent needs. Compare that sum against the license, and demand the same custody answers from the vendor that you would demand from your own build.
