The data platform market has spent three years removing friction between systems, from Salesforce’s zero-copy integration with Snowflake in September 2023 to Workday’s in October 2026. Zero-copy sharing, native connectors, bidirectional integrations, federated query. Each one means faster development, and most mean less data movement and less duplication.
Each one also means one more layer between the query that costs money and the person who caused it.
This is not an argument against integration. Moving less data is usually better than moving more. It is an argument for noticing what integration does to attribution, because the two move in opposite directions and only one of them gets announced.
What gets harder
When a workload runs entirely inside one warehouse, attribution is tractable. You have a query, a user, a warehouse and a cost.
When an external platform queries your data in place through a zero-copy interface, several of those anchors become less useful. If the platform pushes its queries down to Snowflake, the compute is yours. The intent belongs to a system your team does not administer. The user is often a service account. And the query may have been generated by an application rather than written by a person, which makes “who ran this” an unhelpful question.
The bill still arrives. What degrades is your ability to say what it bought.
Three questions worth asking before the next integration
Which side pays? In federated and zero-copy arrangements this is not always obvious, and it is worth establishing before the architecture review rather than after the first invoice. Take Salesforce Data 360 (formerly Data Cloud). In live query federation, Data 360 writes the SQL and a warehouse in your Snowflake account runs it, so one request can draw on both bills. In file federation, which works on Iceberg tables, Salesforce reads the files with its own compute.
What identifies the workload? If every query from the integrated platform arrives under one service account, you have a single line item where you needed a breakdown. In Snowflake, give each integration its own service user and its own warehouse, and tag both. The tagged warehouse then shows the integration’s full compute cost, idle time included, and a custom budget can track everything with that tag. If the platform can set a query tag per workload, the QUERY_ATTRIBUTION_HISTORY view can split the cost further, though it leaves out idle time.
Who reviews it? An integration often has an owner during implementation and no owner afterwards. The spend it generates is nobody’s line item, which is how it grows without anybody deciding it should.
The pattern, not the partnership
Specific partnerships will keep being announced, and the details will differ each time. When Snowflake and Palantir announced bidirectional, zero-copy interoperability in October 2025, the release did not say whose compute would run the queries. Palantir’s documentation does: Foundry can read Snowflake Iceberg tables registered in Horizon Catalog directly from storage with its own compute, while the Snowflake warehouse you configure still runs some metadata queries and everything else. The pattern does not change: an abstraction layer is added, friction falls, visibility falls with it, and the teams that stay in control tend to be the ones who set up attribution at the point of integration rather than after the quarter closes.
The right time to decide how you will measure a new integration is while you are still deciding whether to build it.
