Warehouse-native GTM stack — activation without a second copy of the truth

The warehouse already holds the definition of a qualified account. This stack stops you from maintaining a second copy of it inside a marketing tool. Snowflake or BigQuery owns the modeled customer table, Hightouch syncs it outward, Clay supplies the fields the warehouse cannot produce on its own, and HubSpot is where a human acts on the result.

The argument for building it this way is not architectural taste. It is that any GTM tool with its own segment builder eventually disagrees with dbt about who counts as a customer, and reconciling those two definitions every quarter costs more than the activation layer costs per year. Budget 6-10 weeks to stand up, most of it spent on the data model rather than on any of the three tools.

How the pieces fit

• The warehouse is the source of truth. Snowflake, BigQuery, Databricks or Redshift — the stack is agnostic about which, with one caveat in Variations below. Your dbt models produce one account-level table with the fields GTM actually acts on: ICP tier, fit score, product-usage state, open-pipeline flag. Nothing downstream defines a segment. Downstream tools read one. This is the layer that makes the rest of the stack defensible in a board meeting, and it is also the layer nobody sells you.

• Hightouch is the activation bus. You write SQL against the warehouse, define a sync, and rows land as fields in HubSpot, audiences in ad platforms, or profiles in lifecycle tools — no second copy of customer data in a vendor’s storage. The free Basic Reverse ETL tier is capped at 2 active syncs but carries unlimited destinations and unlimited user seats; the paid Composable CDP tier meters on monthly tracked rows rather than seats, which is why a 40-person growth org costs the same as a 4-person one at equal volume. One provisioning detail to handle during the trial: Hightouch’s docs state the first-party MCP server is not enabled in all workspaces and you must ask for it, even though it carries no surcharge.

• Clay is the gap-filler. The warehouse holds what you observed. Clay supplies what you never saw: firmographics, headcount deltas, technographics, job changes. Its Snowflake integration ships Insert Row, Lookup Row and Upsert Row actions, so an enrichment run writes back into a staging table instead of terminating in a Clay table nothing else reads. As of August 2026 Clay’s BigQuery integration page is still marked Coming Soon — that asymmetry decides your plumbing, not your architecture.

• HubSpot is the action layer, not the truth layer. Owner assignment, sequence enrollment, deal stages, tasks. The operating discipline that makes this stack hold: any HubSpot property written by a Hightouch sync is off-limits to manual edits. If a rep can overwrite icp_tier in the CRM UI, you have two sources of truth again and the whole premise is gone. Lock those properties down on day one.

Named handoffs

1. Model to CRM. dbt materializes gtm_accounts → Hightouch sync reads it → HubSpot company properties (icp_tier, fit_score, next_best_action) update. Only changed rows should bill against the tracked-row meter, which is a property of your model, not of Hightouch.
2. Gap to enrichment. A warehouse view of accounts missing firmographics → Clay Lookup Row or table import → enrichment run → Clay Upsert Row writes into clay_enrichment_staging → dbt merges it into the account model → the next Hightouch sync carries the new fields outward.
3. Property change to sales motion. icp_tier flips to Tier 1 → a HubSpot workflow assigns an owner and enrols the contact in the matching sequence. This handoff lives entirely inside HubSpot; Hightouch’s responsibility ended at the write.
4. Outcome back to the warehouse. Deal stage, sequence outcome and closed-won status return to the warehouse so the next model run scores against outcomes rather than guesses. This is the leg where the tiering decision below bites hardest.

Why this combination

The obvious alternative is to drop Hightouch and use HubSpot’s own warehouse sync in both directions. Run the numbers before you do. HubSpot’s documentation puts the Snowflake sync behind Data Hub or Smart CRM at the Enterprise level plus HubSpot Credits, states plainly that syncs run on a schedule and do not update in real time, and caps a source table or view at 10 GB, 200 columns and 30 million records per sync run. Data Hub Enterprise lists at $2,000/month. The in-house option is therefore $24,000 a year, scheduled-only, and serves exactly one destination — the CRM you already own.

Hightouch’s median annual contract is $15,000 across 170 analyzed purchases, per Vendr, with a range of $9,600 to $75,000 and an average 26% discount off list. For less than the HubSpot tier upgrade you get the CRM leg plus every ad, lifecycle and support destination in a 300-plus integration catalog. The comparison only favours HubSpot if the CRM is genuinely your sole destination forever — and in that case you do not need this stack at all.

The second reason is that each layer owns exactly one job. The warehouse defines, Hightouch moves, Clay fills, HubSpot acts. When a number is wrong, there is one place to look. Stacks that blur those boundaries — a CDP that also models, a CRM that also enriches — produce the failure mode where three tools each hold a slightly different revenue figure and nobody can say which is right.

Cost reality

Annual bands for a 10-seat mid-market B2B team at moderate volume:

• Warehouse (incremental only): BigQuery publishes $6.25 per TiB scanned on-demand in the US multi-region and $0.06 per slot-hour on its Enterprise edition. Snowflake shows no static list price on its pricing page — rates vary by platform and region — and third-party trackers put Standard near $2.00-$2.50 per credit and Enterprise near $3.00. Treat GTM activation as an increment on an existing bill, realistically $2K-$12K/year, driven far more by sync frequency than by row count.
• Hightouch: $15,000/year median per Vendr. The same source puts the bands near $1,000-$2,500/month up to 100,000 monthly tracked rows and $2,500-$8,000/month from 100,000 to 1 million. Nothing beyond the free tier is published, so every figure here is buyer-reported rather than vendor-quoted.
• Clay: Launch is $185/month ($167 billed annually), Growth is $495/month ($446 billed annually), following the March 11, 2026 repricing that split billing into Data Credits and Actions. Self-serve teams land at $2,000-$5,400/year; Enterprise contracts have been reported around a $30,000/year median.
• HubSpot: Sales Hub Professional is $90/seat/month billed annually ($100 billed monthly), so $10,800/year for 10 seats, plus a one-time $1,500 onboarding fee. Enterprise is $150/seat/month.

Total: roughly $30K-$60K/year for 10 seats, with Hightouch as the largest line. Add $24,000 if you also buy Data Hub Enterprise — which, if you are buying Hightouch, you mostly should not.

The costs that do not appear on any invoice: dbt model build and ongoing maintenance, which is the real price of admission; warehouse compute attributable to sync schedules set by habit rather than business need; and Clay top-ups, which bill above your plan rate once either meter runs dry.

Match rules

Use this stack when:

• A warehouse is already in production with a modeled account or customer table. Activation does not create data; buying it before you have a model means paying for an empty pipe.
• Someone owns the dbt project and will still own it in a year. This stack has a named maintainer or it decays.
• You have two or more activation destinations, or expect to within 12 months. One destination does not justify an activation bus.
• You can point at a segment definition that currently exists in both dbt and a vendor UI, and name the last time they disagreed. That is the specific pain this stack removes.

Do not use this stack when:

• You have no warehouse. Buy a packaged CDP that collects events itself; you need ingestion and identity before you need activation.
• HubSpot is your only destination and will stay that way. HubSpot’s native Snowflake sync is slower and tier-gated, but it is one vendor and one invoice.
• Nobody on the team writes SQL. The warehouse-native pattern trades vendor UI for SQL, and that trade is only good if you can make it.
• You are pre-product-market-fit and still learning which signals predict conversion. This stack operationalises a definition of a good account; it does not discover one.

Common variations

• BigQuery instead of Snowflake. Everything holds except the Clay leg — the native BigQuery connector is not shipped yet, so route enrichment through a Hightouch sync into Clay’s HTTP API (Growth plan and above) and have Clay write back along the same path. Adds one hop and changes nothing about the data model. Swap back to the native actions if and when the connector ships.
• Salesforce instead of HubSpot. The right swap when the buyer’s procurement or an existing Salesforce org forces it. Hightouch’s destination catalog covers it either way, so the activation layer is unaffected; what changes is that Salesforce’s own data-cloud pitch will compete for the same budget, and it will not be cheaper.
• Drop Clay. If firmographic enrichment already arrives in the warehouse — a ZoomInfo or Clearbit data share, or a vendor feed your data team already ingests — Clay is redundant here and is the most droppable line in the stack. Keep it only if per-account AI research is doing work a bulk feed cannot.
• Fivetran Census instead of Hightouch. Fivetran acquired Census in May 2025 and folded it in as Fivetran Activations. Pick it if you already buy Fivetran for ingestion and want one invoice; pick Hightouch if activation is the harder half of your problem, where the destination catalog and identity layers are deeper.

What this stack does NOT replace

• The dbt models. Hightouch broadcasts whatever definition you hand it, to 300 destinations, faithfully and fast. A wrong definition gets wrong everywhere.
• Ingestion. Fivetran, Airbyte or native connectors put the data in the warehouse; this stack starts after it lands and does nothing to get it there.
• Identity resolution you have not done. If a person appears three times across product, billing and CRM, activation will sync three of them.
• A demand engine. Paid, content and outbound produce the accounts this stack scores and routes; it processes volume, it does not create it.
• Conversation intelligence and sales methodology. Once the sequence fires and a meeting is booked, this stack has no further opinion — see Gong for what happens next.