Zero copy has become the default direction of travel for how customer data platforms reach customer data. Across the major vendors, the pattern is converging: rather than ingesting a second physical copy of customer records, the platform queries the data where it already lives — in Snowflake, BigQuery, Databricks, or Redshift — and moves only results. Salesforce reports that in Q3 FY2026, of 32 trillion records entering Data Cloud, roughly 15 trillion arrived through zero-copy connectors rather than ingestion, a figure the company describes as a 341% year-on-year increase.

The convergence hides a problem for buyers. “Zero copy” now labels a spectrum of implementations that share a slogan but not a set of constraints. At one end sits genuine federation, where the warehouse remains the system of record and the platform is a query layer over it. At the other sits a scoped feature bolted onto a copy-first product, where federation is permitted for one narrow task and forbidden for the rest. A team comparing two vendors’ zero-copy claims is frequently comparing marketing labels that conceal materially different limits on unification, latency, and supported engines.

This article defines zero copy mechanically, sets it against the copy-first model it is displacing, works a retail example through both approaches, and then examines how five leading platforms implement it — and, more usefully, where each one stops.

Zero copy defined: querying data in place instead of moving it

Zero copy describes an integration pattern in which a customer data platform accesses data held in an external analytical store without ingesting a separate physical copy into its own storage. The platform registers a connection to the source, reads the source’s table metadata, and resolves queries by pushing computation down to the source engine or by reading the source’s underlying files directly. Only the query result — a set of identities, an audience membership, a set of attributes — is returned to the platform.

Two mechanisms dominate current implementations. The first is query federation: the platform translates an operation, such as an audience definition, into SQL and pushes that query to the source warehouse, which executes it and returns rows. The second is open-table-format sharing, where the source exposes its tables in Apache Iceberg or Delta Lake format and the consuming platform reads those tables through a shared catalog without a copy or a format conversion. Salesforce’s connectors, for instance, read Snowflake and BigQuery through Iceberg metadata and bridge Databricks Delta tables into the same path; the data is scanned in place rather than reloaded.

The defining property is that there is one physical copy of the record and one place it is governed. The platform holds a reference and a query plan, not a duplicate. This is the mechanism the rest of the comparison turns on, because vendors differ chiefly in what they will let a reference-and-query-plan do once it exists.

The copy-first model and why its costs stopped paying off

The model zero copy is displacing is straightforward: every source system is piped into the platform’s own store, where records are re-materialised, unified, and activated. For most of the packaged CDP era this was the only option, because the platform’s identity resolution and segmentation ran against its internal database and nothing else.

The copy-first approach carries four recurring costs. The first is duplication: customer data that already exists in the warehouse is stored a second time inside the platform, and paid for twice. The second is latency: because activation runs against the copy, the copy must be refreshed on a schedule, and audiences are only as fresh as the last sync — frequently hours, sometimes a day, behind the source. The third is source-of-truth drift: once two governed copies of the same records exist, they diverge, and reconciling which system holds the correct value becomes an ongoing operational burden. The fourth is movement cost: re-ingesting large volumes incurs egress and processing charges, which at scale become a visible line item. Salesforce, comparing its own paths, cites traditional ingestion at 2,000 Data Cloud credits per million records against roughly 70 for zero-copy federation — an illustrative but pointed contrast in the cost of moving versus referencing.

None of this made copy-first wrong for its era. When the warehouse was immature or absent, the platform’s internal store was the only place unification could happen. The costs stopped paying off as the cloud data warehouse became the enterprise’s actual system of record, at which point the second copy inside the CDP became redundant infrastructure rather than necessary infrastructure.

A retail example: the same audience, copied and federated

The contrast is clearest on a concrete task. Consider — as an illustrative scenario rather than a named customer — a retailer whose loyalty transactions, point-of-sale records, and ecommerce events already land in a cloud warehouse, and whose marketing team wants a single audience: high-value loyalty members who purchased in a given category in the last thirty days and have since lapsed.

Under the copy-first model, the loyalty, POS, and ecommerce tables are ingested into the CDP’s own store on a sync schedule. The audience is then computed inside the platform. Three consequences follow mechanically. The customer records now exist twice, in the warehouse and in the platform, and are billed and secured in both. The audience reflects the state of the last sync, so a member who transacted this morning may not qualify until tonight’s load completes. And the personally identifiable fields in the audience — email, loyalty ID, purchase history — are now governed under two policies in two systems, doubling the surface that compliance must track.

Under zero copy, the same audience definition is translated into SQL and pushed to the warehouse, which already holds all three tables joined by the retailer’s own keys. The warehouse computes membership and returns only the qualifying identities and the attributes needed for activation. There is no second copy to bill or secure, the result reflects the warehouse’s current state rather than a stale sync, and the governed copy of the customer’s data never leaves the boundary the retailer already controls. The audience is the same; the number of governed copies, the freshness, and the compliance surface are not.

Why zero copy is the new move, not merely a cheaper pipe

Zero copy is frequently presented as a cost optimisation, but the more consequential change is architectural. Copy-first treats the CDP as the system of record: the place where the authoritative customer profile is assembled and held. Zero copy inverts that relationship. The warehouse becomes the system of record, and the platform becomes a logic layer — identity resolution, segmentation, and activation expressed as computation over data it does not own.

That inversion is what makes the pattern more than a discount. It collapses the governance problem from two copies to one, so access policy, retention, and lineage are enforced once, at the source, rather than reconciled across systems. It changes the freshness ceiling from the sync interval to the warehouse’s own currency. And it aligns the CDP with the composable and warehouse-native direction the broader customer data infrastructure layer has been moving in, where reverse-ETL and activation tools already operate on the warehouse rather than beside it. The reason the major vendors are all shipping zero-copy connectors is not principally price; it is that the warehouse has already become the place the data lives, and a platform that insists on a second copy is now arguing against its customers’ own architecture.

The qualification worth stating plainly is that federation is not free of trade-offs. Pushing queries to the source consumes the source’s compute, and a poorly bounded federated query can be slower or more expensive than reading a local copy. Where a workload needs sub-second profile lookups at high concurrency, a purpose-built low-latency store still has a role. Zero copy wins the default case; it does not abolish every reason a copy might exist.

How the top five vendors implement zero copy — and where each one stops

The vendors converge on the slogan and diverge on the constraints. Five implementations mark out the current spectrum.

Salesforce Data Cloud sits at the broad-federation end. It connects to Snowflake, BigQuery, Databricks, and Redshift, reading them through Iceberg and Delta metadata, and — critically — allows the federated data to participate in unification and activation, not merely one task. Its published volumes (the 15-trillion-record zero-copy figure above) reflect that breadth. The limit is gravitational rather than technical: the pattern pulls the customer toward Salesforce’s own semantic and activation layer as the place logic is expressed.

Adobe Real-Time CDP, through Federated Audience Composition, occupies the scoped-feature position. It pushes SQL down to any of several supported warehouses and returns audience membership without a copy. The hard limit is explicit in Adobe’s own documentation: federated data may be used to compose audiences, but not for profile unification — the resolved profile still lives in Adobe’s copy-first store. Zero copy here is a feature attached to a copy-first product, not the architecture of the product.

Hightouch approaches from the composable end, where zero copy is not a feature because a copy never existed. The platform operates directly on the warehouse as a logic layer, resolving identity and building audiences in place and activating outward. There is nothing to federate against because the warehouse was always the store. The trade-off is that the buyer must already run a capable warehouse; Hightouch supplies the logic, not the data platform.

Databricks CustomerLake, launched in mid-2026, represents the native-lakehouse position: CDP capabilities — identity resolution, segmentation, campaign agents, partner activation — built directly into the lakehouse. Zero copy is trivially true because the data never leaves the platform it was already in. The constraint is the inverse of Hightouch’s: the model assumes the customer’s data already lives in Databricks.

Snowflake, as the warehouse itself, anchors the spectrum’s foundation. Its native sharing and increasingly its native application ecosystem let CDP logic run against data that never moves off the platform, with governance enforced at the source. The constraint is that Snowflake supplies the substrate and the sharing primitives; the customer-facing CDP logic still comes from a partner or a native app built on top.

The pattern across the five is consistent. The question that separates them is not whether they support zero copy — all now claim it — but what the federated data is permitted to do: unify, or only compose; run in place, or feed a copy that still does the real work.

Conclusion

Zero copy has won the argument about direction. The copy-first model made sense when the warehouse was not yet the system of record, and it stops making sense once it is — which for most enterprises it now is. But the convergence on the slogan is exactly what makes it unreliable as a buying signal. Salesforce’s broad federation, Adobe’s audience-only pushdown, Hightouch’s copy-that-never-was, Databricks’ native lakehouse, and Snowflake’s shared substrate are five different architectures wearing one word.

The practical move is to stop evaluating the label and start evaluating the constraint behind it. For any vendor claiming zero copy, the questions that separate the spectrum are answerable in a single meeting: can the federated data be used for identity resolution and unification, or only for audience composition? Is the result live against the warehouse, or does a scheduled copy still do the activation? Which specific engines and table formats are supported, and which are not? The answers place a vendor on the spectrum far more reliably than the slogan does.

Where to go next

Teams evaluating a zero-copy claim against their own architecture can work through it structurally rather than by demo. The packaged-versus-warehouse-native evaluation toolkit on this site sets out the questions to put to each vendor — on unification, freshness, and supported engines — before a single connector is configured.

Frequently Asked Questions