- Not all CDPs connect to Snowflake, BigQuery, and Databricks the same way. Some copy your data out; others query it in place via pushdown SQL or native compute layers like Snowpark.
- Snowflake has the deepest native app catalog for marketing activation, with vendors like Hightouch and Census operating directly inside Snowflake’s compute without data egress.
- BigQuery activation is strong through Google-native tooling and reverse ETL, but fewer vendors offer true zero-copy operation there compared with Snowflake.
- Databricks is the least-served by traditional CDPs. Hightouch and dbt-native tooling cover it, but Databricks’ own CustomerLake product is the clearest native-first answer on that platform.
- The matrix below is organized by warehouse, not vendor rank, because your warehouse choice constrains your activation options more than any single CDP feature list.
CDP and activation vendor support for Snowflake, BigQuery, and Databricks varies sharply in depth. Hightouch and Census run natively inside Snowflake as Native Apps and support Databricks and BigQuery via pushdown SQL. Tools like Segment and Braze connect to all three via connector-based data pulls. Databricks’ own CustomerLake is the only product embedded in the Databricks lakehouse itself. Choosing a warehouse without checking activation depth first is one of the more common and expensive procurement mistakes in the modern data stack.
Why Warehouse Choice Is an Activation Decision, Not Just an Infrastructure One
Most marketing teams pick their warehouse for engineering reasons: cost per query, ML workload support, existing cloud contracts. Activation comes up later, usually when a growth or MOps team tries to sync audiences to Salesforce or push segments into a paid media platform and discovers that their preferred CDP does not support their warehouse at the depth they expected.
The distinction that matters most is between connector-based support and native compute support. Connector-based support means a vendor pulls data out of your warehouse, processes it on its own infrastructure, and writes results somewhere. Native compute support means the vendor’s logic runs inside your warehouse’s compute layer, so data never leaves. For teams with strict data residency requirements or very large audience tables, this difference in architecture translates directly into cost, latency, and compliance posture.
This article covers Snowflake, BigQuery, and Databricks specifically because those three dominate enterprise and mid-market data stack decisions. For a broader look at how zero-copy and replication architectures differ across vendors, the vendor-by-vendor breakdown of CDP data replication vs. query pushdown on AboutMartech covers the underlying mechanics in detail.
What Does “Native” Support Actually Mean for a CDP?
The word “native” gets used loosely by vendors. For the purposes of this article, AboutMartech applies what we call the Warehouse Depth Test, a four-check framework for evaluating how deeply an activation tool actually runs on a given warehouse.
Check 1: Compute location. Does the vendor’s SQL and transformation logic execute inside the warehouse’s compute, or on the vendor’s own servers? Native means warehouse compute.
Check 2: Data movement. Does the vendor copy your audience data to its own storage before processing, or does it read directly from your warehouse tables? Zero-copy means no movement.
Check 3: Marketplace listing. Is the product installable from the warehouse’s native marketplace (Snowflake Marketplace, Google Cloud Marketplace, Databricks Marketplace) without leaving the platform? Marketplace distribution is a strong signal of genuine integration depth.
Check 4: API surface used. Does the vendor use standard JDBC/ODBC connectors (shallow), or does it use platform-specific APIs like Snowpark, BigQuery Storage API, or Databricks SQL Warehouse? Platform-specific API usage indicates the vendor has invested in depth, not just a checkbox integration.
A vendor that passes all four checks is genuinely native. Most pass one or two. That gap is what this article maps.
Which Activation Tools Run Natively Inside Snowflake?
Snowflake has the most mature native app catalog of the three warehouses for marketing activation. Snowflake Native Apps, built on the Snowflake Native App Framework, allow vendors to deploy their application logic inside a customer’s Snowflake account. Data never leaves the customer’s Snowflake environment.
Hightouch operates as a Snowflake Native App. Its audience builder and sync engine run inside Snowflake compute using Snowpark, which means Hightouch never receives a copy of your customer data. Audience queries execute as Snowpark jobs within your account. This architecture passes all four checks in the Warehouse Depth Test.
Census similarly supports Snowflake deeply, using pushdown SQL to execute transformation logic inside Snowflake rather than pulling data to Census servers. Census is also listed on Snowflake Marketplace. Both Hightouch and Census support Snowpark-native execution for compute-intensive audience workloads.
Segment (Twilio) connects to Snowflake as a source and destination via its Reverse ETL feature, but it pulls data to Segment’s own infrastructure for processing. It does not run as a Snowflake Native App. For teams evaluating Segment on Snowflake, that connector-based architecture means data egresses before activation.
RudderStack supports Snowflake as a warehouse destination and offers Reverse ETL with Snowflake as a source, using pushdown queries. It does not offer a Snowflake Native App but does execute SQL inside Snowflake before syncing results. It passes checks 1 and 4 but not 3.
For B2B teams specifically evaluating Hightouch against Census on Snowflake, the Hightouch vs. Census reverse ETL comparison covers that matchup in detail.
Which CDPs and Activation Tools Support BigQuery for Marketing Activation?
BigQuery activation sits in an interesting position. Google’s own ad tech stack connects directly to BigQuery through Google Cloud’s native integrations, making BigQuery the strongest warehouse for Google Ads, DV360, and GA4 audience activation without any third-party tooling. If your paid media is primarily Google, BigQuery is the path of least resistance.
Outside Google’s own tools, the picture is more mixed. Hightouch supports BigQuery with pushdown SQL, executing queries inside BigQuery compute before syncing results downstream. It uses the BigQuery Storage API for high-throughput reads, which is materially faster than standard connector-based extraction for large audience tables. Census supports BigQuery similarly, with pushdown query execution and BigQuery listed as a supported warehouse source.
Segment supports BigQuery as a Reverse ETL source, pulling data to Segment infrastructure for processing. It does not run inside BigQuery compute. dbt has deep BigQuery support and is commonly used to build audience models directly in BigQuery, which downstream activation tools then read. This dbt-in-warehouse approach is increasingly common for teams that want to keep identity resolution and segmentation logic version-controlled and inside their warehouse.
One meaningful constraint: BigQuery does not have a native app marketplace equivalent to Snowflake’s Native App Framework. Vendors cannot deploy application logic inside a customer’s BigQuery account the same way they can in Snowflake. This means the zero-copy native compute pattern that exists in Snowflake does not have a direct equivalent in BigQuery today. Every BigQuery activation tool, even the best ones, is extracting data at some point.
Google’s own BigQuery integrations for marketing teams, including the BigQuery Data Transfer Service and Ads Data Hub, do allow audience activation that stays within Google’s infrastructure, which partially compensates for the lack of third-party native apps.
Which Tools Work for Marketing Activation on Databricks?
Databricks is the most underserved of the three warehouses for marketing activation, at least from traditional CDP vendors. Most CDPs built before 2022 were architected around Snowflake and BigQuery. Databricks’ positioning as a lakehouse, combining data lake storage with warehouse-style SQL, means its customer profile data often lives in Delta tables that older connectors cannot query efficiently.
The most significant development here is CustomerLake, Databricks’ own agentic CDP product announced in 2025. CustomerLake is embedded inside Databricks’ lakehouse, uses Lakehouse Federation to access data across Databricks, Snowflake, BigQuery, and other sources, and positions itself as the native-first answer for teams whose primary warehouse is Databricks. It is the only product that genuinely passes all four checks of the Warehouse Depth Test for Databricks specifically.
Hightouch supports Databricks as a warehouse source, using Databricks SQL Warehouse for pushdown query execution. It can sync audiences built on Delta tables to downstream destinations without full data extraction. Census also supports Databricks SQL, with similar pushdown architecture.
RudderStack supports Databricks as a source and destination but uses standard JDBC-style connectivity rather than Databricks-native APIs in most configurations. This makes it functionally usable but not deeply native in the sense of the Warehouse Depth Test.
For teams running ML-driven propensity models in Databricks MLflow and wanting to activate those scores directly into campaign audiences, CustomerLake is the only tool that reads those artifacts natively. Every other activation vendor requires exporting scores to a table first, which adds latency and a pipeline dependency.
Warehouse Compatibility Matrix: CDP and Activation Tool Support Depth
The matrix below applies the Warehouse Depth Test to each vendor across all three warehouses. “Native compute” means the vendor’s logic executes inside the warehouse. “Pushdown SQL” means queries run in the warehouse but the vendor processes results externally. “Connector-based” means data is extracted before processing.
| Vendor | Snowflake Support Depth | BigQuery Support Depth | Databricks Support Depth | Marketplace Listed | Zero-Copy Possible |
|---|---|---|---|---|---|
| Hightouch | Native App (Snowpark) | Pushdown SQL + Storage API | Databricks SQL pushdown | Snowflake, Databricks | Yes (Snowflake only) |
| Census | Pushdown SQL, Marketplace | Pushdown SQL | Databricks SQL pushdown | Snowflake | Partial (Snowflake) |
| Segment (Twilio) | Connector-based Reverse ETL | Connector-based Reverse ETL | Limited/connector-based | No | No |
| RudderStack | Pushdown SQL | Pushdown SQL | JDBC/connector-based | No | No |
| CustomerLake (Databricks) | Federation read | Federation read | Native lakehouse (full) | Databricks | Yes (Databricks only) |
| Google Ads Data Hub / BQ | No | Native (Google-owned) | No | Google Cloud Marketplace | Yes (BigQuery only) |
| dbt + activation layer | Native SQL execution | Native SQL execution | Native SQL execution | All three (dbt Cloud) | Yes (all three, model-layer) |
Note: “Zero-copy possible” refers to whether the vendor can activate audiences without moving raw customer data outside the warehouse. dbt itself does not activate; it models. Activation requires a downstream sync tool when using dbt alone.
What Does Cross-Cloud Activation Look Like When Your Data Is Split?
A common situation in enterprise teams: raw event data in BigQuery (because the engineering team uses GCP), but a Snowflake contract already in place from a previous initiative, and Databricks running ML workloads. Activation vendors that market themselves as “multi-cloud” often mean they support all three as separate connectors, not that they can join data across them.
True cross-cloud activation requires either data sharing (Snowflake Data Sharing, BigQuery Analytics Hub, Databricks Delta Sharing) or a federation layer. CustomerLake uses Lakehouse Federation explicitly for this, which makes it the most credible answer for teams with data genuinely distributed across warehouses. Hightouch supports multiple warehouse sources per account, but audiences must be built from a single warehouse source per sync, not joined across warehouses in real time.
For most mid-market teams, the practical answer is to consolidate activation data into one warehouse before building audiences, then use a tool native to that warehouse. Cross-cloud activation in real time remains an architectural challenge that no activation tool solves cleanly today, vendor marketing notwithstanding.
Teams building first-party data stacks often encounter this fragmentation challenge early. The guide to building a first-party data stack after cookie deprecation covers consolidation patterns that reduce cross-cloud complexity before activation tooling is selected.
Can You Activate BigQuery Audiences Without Moving Data?
Not fully, with third-party tools. BigQuery does not have a native app framework equivalent to Snowflake’s, so third-party activation vendors cannot deploy their compute inside a customer’s BigQuery account. What you can do: use pushdown SQL tools like Hightouch or Census to minimize data movement (queries run in BigQuery, only results are transferred), or use Google’s own tooling like Ads Data Hub, which processes audience data inside Google’s infrastructure without sending it to a third party. For strict data residency requirements, Google’s own stack on BigQuery is currently the most credible zero-copy answer.
Which Vendors Are Snowflake Native Apps for Marketing?
As of their public documentation, Hightouch is available as a Snowflake Native App, running its sync and audience logic inside a customer’s Snowflake account via Snowpark. This is the most architecturally significant Snowflake native deployment in the marketing activation space. Other vendors, including Census, are listed on Snowflake Marketplace but operate primarily via pushdown SQL rather than as full Native Apps with in-account compute deployment. The distinction matters for data governance teams: a Native App deployment means vendor code runs in your account; a Marketplace listing does not guarantee that.
What Is the Right CDP Architecture If Your Warehouse Is Databricks?
If Databricks is your primary warehouse, the decision tree is shorter than it looks. CustomerLake is the only product built natively for the Databricks lakehouse, and it is the logical first evaluation. For teams that need broader downstream destination coverage than CustomerLake currently offers , Databricks has not publicly detailed CustomerLake’s destination catalog at the same level of specificity as Hightouch or Census, so teams should request a current destination list directly from Databricks during procurement , Hightouch on Databricks SQL covers the reverse ETL activation layer with good destination breadth. Using both is not uncommon: CustomerLake for identity resolution and audience modeling within Databricks, Hightouch for syncing those audiences to Salesforce, HubSpot, paid media platforms, and email tools.
Teams evaluating warehouse-native CDPs more broadly, including options beyond these three platforms, will find the warehouse-native CDP comparison on AboutMartech useful as a companion read.
Warehouse Compatibility FAQ
Can I activate BigQuery audiences without moving data to a third-party CDP?
Partially. BigQuery lacks Snowflake’s Native App Framework, so third-party vendors cannot deploy their compute inside your BigQuery account. Tools like Hightouch and Census use pushdown SQL to minimize egress, running queries inside BigQuery before transferring only results. Google’s own Ads Data Hub processes audience data within Google’s infrastructure without third-party exposure. For strict zero-copy requirements on BigQuery, Google’s native stack is the most defensible architecture today.
Which activation tools are available as Snowflake Native Apps?
Hightouch is the most prominent marketing activation vendor operating as a Snowflake Native App, deploying its sync and audience engine inside a customer’s Snowflake account via Snowpark. Other vendors list on Snowflake Marketplace but do not necessarily deploy as full Native Apps with in-account compute. If data residency or governance requirements prohibit sending data to a vendor’s servers, verifying Native App status specifically (not just Marketplace listing) is a required step during procurement.
What is the difference between query pushdown and a native app in a warehouse?
Query pushdown means a vendor sends SQL to your warehouse, executes it there, and retrieves results to its own servers for further processing. A native app means the vendor’s application code is deployed and runs entirely inside your warehouse account, so neither raw data nor intermediate results leave your environment. Native apps offer stronger data residency guarantees. Pushdown SQL is a meaningful improvement over full data extraction but is not the same as in-account compute deployment.
Is Snowflake a CDP?
Snowflake is a cloud data platform, not a CDP. It stores and processes data but does not natively provide identity resolution, audience segmentation, or activation to downstream marketing destinations. Several vendors have built CDP-like functionality on top of Snowflake using its Native App Framework, including Hightouch’s audience builder. Snowflake Data Cloud positions itself as a foundation for composable CDP architectures rather than a CDP itself. The distinction matters when evaluating whether you need a warehouse-native activation tool on top of Snowflake.
Does Segment support Snowflake, BigQuery, and Databricks equally?
No. Segment supports all three as Reverse ETL sources, but uses connector-based extraction for each, pulling data to Segment’s own infrastructure before processing. Segment does not offer Snowflake Native App deployment or pushdown SQL execution inside any warehouse. For teams whose primary reason to evaluate a CDP is deep warehouse integration with zero data egress, Segment’s architecture is a weaker fit than Hightouch or Census on Snowflake or BigQuery.
What is Databricks CustomerLake and how does it compare to traditional CDPs?
CustomerLake is Databricks’ own agentic CDP product embedded in the Databricks lakehouse, announced in 2025. It uses Lakehouse Federation to access customer data across Databricks, Snowflake, BigQuery, and other sources without requiring full data replication. Unlike traditional CDPs that ingest data into their own infrastructure, CustomerLake processes data where it already lives. It is the only activation product that reads Databricks MLflow artifacts and Unity Catalog natively. Databricks has not publicly published a full destination catalog for CustomerLake at the level of detail Hightouch and Census provide; teams with specific downstream destination requirements should request that list directly from Databricks during evaluation.
How do reverse ETL tools differ from native CDP apps on Snowflake?
Reverse ETL tools like Hightouch and Census read from a warehouse and sync records to downstream destinations. When they operate as Snowflake Native Apps, the read and processing logic runs inside Snowflake compute. Traditional CDPs ingest data into their own storage layer and manage their own identity graph, then connect to warehouses as an optional data source or destination. Warehouse-native reverse ETL treats the warehouse as the system of record and the CDP as an activation layer, which is architecturally different from legacy CDP deployments where the vendor’s infrastructure is primary.
How to Map Your Warehouse to the Right Activation Stack
The choice of warehouse is functionally a constraint on your activation options, more so than most teams realize when they sign a cloud contract. Snowflake gives you the deepest native app catalog for marketing activation, with Hightouch as the clearest Native App option and Census close behind. BigQuery’s activation depth is strongest within Google’s own ad tech stack, with Hightouch and Census filling the gap for non-Google destinations via pushdown SQL. Databricks is the newest entrant and the least covered by traditional CDP vendors, but CustomerLake changes that calculus meaningfully for teams already committed to the Databricks lakehouse.
The reverse ETL category, covered in more depth in the reverse ETL tools guide on AboutMartech, is where most of the warehouse-to-activation action currently sits. The traditional CDP market’s response has been to add “warehouse-native” modes to existing products, but the architectural gap between a genuine Native App deployment and a JDBC connector relabeled as native is significant. Procurement teams that apply the Warehouse Depth Test , specifically checking compute location, data movement, marketplace listing, and API surface , will find that gap quickly.
For most teams evaluating this space in the near term: if you are on Snowflake, start with Hightouch’s Native App offering. If you are on BigQuery and your activation is primarily Google-channel, evaluate Ads Data Hub and the native BQ integrations before adding a third-party tool. If you are on Databricks, CustomerLake warrants a serious evaluation, with Hightouch as the complement for destination breadth. The warehouse you already have determines the shortest path to activation, and no CDP vendor erases that constraint entirely.
For a wider view of how CDPs are evaluated across B2B use cases, the best CDPs for B2B teams comparison on AboutMartech covers the broader vendor landscape beyond warehouse-native options. Teams specifically comparing pricing across reverse ETL vendors will also find the reverse ETL pricing comparison useful before finalizing procurement.
