Reverse ETL
A reverse-ETL tool — Hightouch, Census, Polytomic, RudderStack — syncs warehouse data into the CRM on a schedule or trigger. Data lives in Snowflake, BigQuery, Databricks, or Redshift; copies flow into Salesforce, HubSpot, Marketo, Iterable, and ad platforms. The model is vendor-neutral and the warehouse remains the source of truth, but it introduces sync state (which row was last synced when), latency (5-minute to hourly cadence is typical), and a separate set of credentials, monitoring, and runbooks. Pricing for Hightouch and Census in 2026 sits in the $25-100K range for mid-market and scales with active rows; Polytomic and RudderStack offer cheaper entry points.
Data 360 Zero-Copy
Salesforce Data Cloud — branded “Data 360” since the 2025 rebrand — queries warehouse data directly through zero-copy federation with Snowflake, Databricks, BigQuery, and Redshift. No sync, no copy in the steady state; the agent or flow asks Data Cloud, which translates the query against the federated source. Lower latency in principle, less sync state to manage, but tightly coupled to the Salesforce stack and dependent on Data Cloud licensing (which carries a credit-based pricing model that can surprise teams running large grounding queries for AI agents). The 2025 zero-copy GA with Snowflake and the 2026 GA with Databricks Iceberg tables changed the calculus for many enterprises.
When Reverse ETL Wins
A multi-vendor activation footprint where data flows to HubSpot, Marketo, Iterable, Salesforce, Facebook Ads, Google Ads, and Klaviyo argues for reverse ETL — the warehouse-to-many fan-out is what these tools were built for. Complex transformations belong in dbt before Census or Hightouch lands them, not in a Salesforce flow. Teams already operating dbt + Snowflake + Hightouch with mature observability often find that adding Data 360 doubles the architecture without paying back. If you are not on Salesforce as the primary CRM, the decision is reverse ETL by default.
When Data 360 Wins
A Salesforce-centric stack with Agentforce in production benefits from Data 360’s real-time grounding: an agent that needs the customer’s last order, current support cases, and lifetime value pulled at request time without a pre-staged sync. Simplified architecture and reducing vendor count are real wins for IT leaders managing too many integrations. The trap is forgetting that zero-copy queries cost Data Cloud credits per scan; a poorly bounded agent can burn through a budget quickly. Most net-new Salesforce deployments in 2026 lean Data 360 first; multi-vendor shops lean hybrid (Data 360 for Agentforce grounding, Hightouch for activation to non-Salesforce destinations).
Decision Criteria
Three questions decide it. First, how many activation destinations? One or two — either pattern works, slight edge to Data 360 if Salesforce-only. Five or more — reverse ETL. Second, do you have Agentforce in production today? Yes — Data 360 is hard to avoid. No — reverse ETL is sufficient. Third, where does your team’s data engineering muscle live? In dbt and Snowflake — reverse ETL fits the existing skill set. In Salesforce admins with Data Cloud certs — Data 360 is the lower-friction path.
Common Failure Modes
The dominant mistake is choosing on vendor relationship rather than architecture fit. The second is underestimating Data Cloud credit consumption when AI agents start grounding heavily. The third is running both tools for overlapping use cases and creating two competing sources of truth — an Account’s “lifetime value” reads differently in Hightouch-synced fields than in a Data 360 federated query, and nobody can tell which is right.
Cost Considerations
Reverse ETL pricing scales with synced rows; expect $25-150K per year for mid-market. Data 360 pricing scales with credits consumed by queries, ingestion, and segmentation; agentic workloads can push this from $50K to $500K depending on volume. Model the AI grounding cost separately from the activation cost — they trend differently as adoption grows.
What to do this week
List your current and planned activation destinations on one column, your AI grounding queries on another. If both columns are non-empty, you are heading to hybrid; design accordingly rather than picking one and back-filling later.
