Hightouch
Reverse ETL: sync the models in your warehouse into the tools your team uses
Hightouch is a composable customer data platform built on reverse ETL: it reads data already modelled in a warehouse such as Snowflake, BigQuery, Databricks, or Redshift and syncs it into business tools like CRM, email, ads, and support platforms. Instead of storing a separate copy of customer data, it treats the warehouse as the source of truth and handles activation on top of it.
Overview
The composable CDP argument is simple: your warehouse already contains the most complete and best-governed version of your customer data, assembled by a data team using models everyone has agreed on. Copying that into a separate vendor's storage to build audiences duplicates the work, creates a second definition of every metric, and puts the resulting logic somewhere analysts cannot see. Hightouch instead activates the warehouse directly.
Operationally, you write a SQL query or select a dbt model, map its columns to fields in a destination, and choose a sync schedule. Hightouch handles the mechanics that make this hard in practice: computing which rows changed since the last run, respecting API rate limits, batching, retrying failures, and reporting exactly which records did not make it and why. Those unglamorous details are the actual product.
Above the sync layer sit audience and personalization tools that let non-technical users build cohorts on warehouse data through a visual interface, plus an AI decisioning layer for choosing message and offer per customer. The result is a CDP whose storage is yours, whose definitions live in version-controlled models, and whose vendor can be replaced without re-instrumenting anything. The requirement, and it is a real one, is that a warehouse with modelled customer data must already exist.
Best for
Companies that already run a cloud data warehouse with modelled customer data and want to activate it in go-to-market tools without duplicating storage or logic into a traditional CDP.
Not the right fit for
- Businesses without a warehouse, since Hightouch activates data rather than collecting it.
- Teams needing event collection from websites and apps as the primary requirement, which is a different product category.
- Organizations with no SQL or analytics engineering capability at all, though the visual audience builder reduces this requirement considerably.
- Buyers wanting messaging execution; Hightouch delivers data to messaging tools rather than sending campaigns itself.
- Real-time personalization at millisecond latency in-page, where an edge-optimized profile store is more appropriate.
How it works
- 1
You connect a warehouse and one or more destinations. Hightouch reads with the permissions you grant and never becomes the primary store, which is what keeps governance in the data team's hands.
- 2
A model defines the data to sync: raw SQL, a dbt model, a Looker look, or a visual query builder for non-technical users. The model's output is a table of rows with a primary key.
- 3
A sync maps that model's columns to destination fields, defines behavior for new, changed, and removed rows, and runs on a schedule or trigger. Change data capture means only differences are sent, which is what makes frequent syncs affordable against rate-limited APIs.
- 4
Observability closes the loop: per-sync run logs, row-level error reporting, alerting into Slack or email, and a live debugger. When a CRM rejects 400 records for a missing required field, the tool tells you which ones and why rather than failing silently.
Feature breakdown
20 features in 4 modulesReverse ETL
The core sync engine and the reliability work behind it.- Warehouse-native models
- Sync from raw SQL, dbt models, Looker looks, or a visual builder, with the warehouse remaining the single source of truth.
- Change data capture
- Only new and changed rows are sent each run, which keeps frequent syncs within destination rate limits and cost budgets.
- Row-level observability
- Per-record success and failure reporting with reasons, so a rejected batch is diagnosable rather than mysterious.
- Retry and rate-limit handling
- Automatic backoff, batching, and retry logic tuned per destination API, the unglamorous engineering that makes syncs dependable.
- Two hundred plus destinations
- CRM, marketing automation, advertising, support, finance, and messaging tools, with custom destinations for anything unsupported.
Audiences and activation
Letting marketers use warehouse data without writing SQL.- Visual audience builder
- Cohorts defined on warehouse tables through a point-and-click interface, executed as SQL underneath.
- Audience splits and holdouts
- Randomized splits and control groups so campaigns built on warehouse data can be measured properly.
- Identity resolution
- Deterministic matching across identifiers to unify records before activation, run inside your own warehouse.
- Journeys and orchestration
- Multi-step, condition-based flows that trigger syncs and messages as customers meet criteria.
- Personalization API
- Low-latency profile lookups for applications that need customer attributes at request time rather than on a schedule.
AI decisioning
Choosing what to send rather than only who to send it to.- Per-customer decisioning
- Models select the best message, offer, or channel per individual rather than applying one rule to a segment.
- Experimentation framework
- Built-in measurement of decisions against holdouts, so incremental impact is estimated rather than assumed.
- Feature access from the warehouse
- Decisions draw on the full modelled dataset rather than only the attributes copied into a marketing tool.
- Guardrails and constraints
- Frequency and eligibility rules that keep automated decisioning inside business policy.
- Outcome reporting
- Results attributed back to warehouse data so performance is measured in the same place revenue is defined.
Platform and governance
Operating it as infrastructure.- Version control and CI
- Sync configuration as code with Git integration and API management, so changes are reviewed rather than clicked into production.
- Environments
- Separate development and production configurations to test a sync before it writes to a live CRM.
- Alerting and monitoring
- Failure notifications to Slack, email, or PagerDuty with configurable thresholds on row-level errors.
- Role-based access control
- Permissions over models, destinations, and syncs, since a misconfigured sync can overwrite a CRM at scale.
- Security posture
- Read-only warehouse access patterns, encryption in transit, and enterprise compliance certifications.
Use cases
4 documentedRevOps lead enriching the CRM
Product usage data lives in the warehouse and sales asks for it in Salesforce every quarter, delivered as a manual CSV.
A scheduled sync writes usage scores and health signals onto accounts continuously, and the CSV ritual ends permanently.
Growth marketer suppressing wasted ad spend
Ads keep serving to existing customers and churned users because the ad platform only knows what was uploaded last month.
Warehouse-defined audiences sync to Meta and Google on a daily schedule, with suppression lists always current.
Lifecycle team personalizing onboarding email
The email tool holds only signup data, so onboarding messaging cannot reference what the user actually did.
Behavioral attributes modelled in dbt sync into the messaging platform as user properties, and messages branch on real usage.
Data team tired of maintaining bespoke sync scripts
Half a dozen Python jobs push data to business tools, each with its own failure modes and no monitoring.
The scripts are replaced by managed syncs with row-level error reporting and alerting, freeing the team from unpaid integration maintenance.
Pricing
from Free tier for limited syncs; paid plans commonly from several hundred dollars per monthSubscription based on destinations, syncs, and activated records, with a free tier for small use and quoted enterprise agreements. Audience and AI decisioning capabilities are licensed above the core reverse ETL product.
| Plan | Price | Includes |
|---|---|---|
| Free | $0 per month |
|
| Business | Quoted, commonly from several hundred dollars per month |
|
| Enterprise | Quoted annual |
|
Billing notes
- Cost drivers are destinations, sync frequency, and the volume of records activated, so a small number of high-frequency syncs can cost more than many daily ones.
- Warehouse compute is billed separately by your warehouse provider, and frequent syncs on large models are a real line item there.
- The audience and decisioning layers are priced above core reverse ETL, so a composable CDP deployment is meaningfully more than a sync tool.
- Enterprise agreements are annual and negotiated; published pricing covers only the lower end of the range.
- Because the data stays in your warehouse, the switching cost is low, which is a useful position in a renewal conversation.
Value assessment: For a company with a functioning warehouse, Hightouch replaces two persistent costs: bespoke sync scripts that nobody wants to maintain, and a traditional CDP's duplicate storage and duplicate definitions. Both are real savings, and keeping logic in dbt where it is reviewed and versioned is worth more than any feature comparison. Against that, warehouse compute rises with sync frequency, and the audience and decisioning layers push the price toward what a conventional CDP costs. The value case is strongest for data-mature teams and weakest for anyone still building the warehouse.
Strengths & limitations
Strengths
- The warehouse remains the source of truth, so metric definitions live in version-controlled models rather than a vendor interface.
- Row-level observability and error reporting turn sync failures into fixable problems rather than silent data loss.
- Very broad destination coverage with a custom destination path for anything unsupported.
- Configuration as code with Git integration and environments, which is rare in go-to-market tooling.
- Low lock-in: the data was never held hostage, so migrating away is a matter of replacing syncs.
- Visual audience builder lets marketers act on warehouse data without depending on the analytics queue.
Limitations
- Requires an existing warehouse with modelled customer data, which excludes a large share of small businesses.
- Does not collect events, so a separate collection layer is still needed for behavioral data.
- Sync latency is bounded by schedule and warehouse compute, so true real-time use cases need the personalization API or another approach.
- Frequent syncs on large models raise warehouse costs that are invisible in the Hightouch invoice.
- The full composable CDP stack, audiences plus decisioning, costs enough to erode the price advantage over traditional CDPs.
- Pricing is largely quoted, making budget forecasting harder than with published per-user tiers.
Head-to-head comparisons
3 alternativesHightouch vs Census
from Free tier for limited syncs; paid plans commonly from several hundred dollars per monthThe closest competitor and a genuinely close call. Both do warehouse-native activation well; Census has historically emphasized data governance, entity modelling, and a strong dbt-centric workflow, while Hightouch has pushed harder into marketer-facing audiences, journeys, and AI decisioning. Data teams choosing a pure sync layer often prefer Census; organizations wanting marketers to self-serve on warehouse data usually prefer Hightouch.
Full Hightouch vs Census comparisonHightouch vs Segment
from Free for up to around 1,000 monthly tracked users; Team plans from roughly $120 per monthDifferent architectures rather than different features. Segment collects events at the edge and stores profiles itself; Hightouch reads what your warehouse already holds. Segment is the better answer when collection is the problem and there is no data team; Hightouch is the better answer when the warehouse is already the best version of the truth and copying it again is the problem.
Full Hightouch vs Segment comparisonHightouch vs Fivetran
from Free for up to around 500,000 monthly active rows; paid usage from roughly $500 per month at modest volumesOpposite directions of the same pipe. Fivetran moves data from sources into the warehouse; Hightouch moves modelled data back out to business tools. They are commonly deployed together with dbt in between, and the pairing is close to a standard architecture for data-mature go-to-market teams.
Full Hightouch vs Fivetran comparisonImplementation & onboarding
- Setup time
- A first sync can be live in an afternoon if the warehouse and destination credentials exist. A full activation program, including identity resolution and audience governance, takes weeks and depends more on data modelling maturity than on the tool.
- Learning curve
- Low for anyone comfortable with SQL or dbt. Marketers need training on the audience builder, and the concept that changes must happen in models rather than in the destination takes some cultural adjustment.
- Onboarding
- Self-serve on lower tiers with strong documentation; enterprise agreements include solution architecture support, which is valuable for identity resolution design.
- Migration notes
- Moving in from bespoke scripts is straightforward, since the models already exist. Moving away is unusually cheap because the data never left your warehouse, so switching cost is limited to rebuilding sync configuration.
Platform, API & security
- Platforms
- Cloud data warehouses (Snowflake, BigQuery, Databricks, Redshift, Postgres)Web applicationAPI and Terraform
- API
- Full management API, Terraform provider, Git-based configuration, and a personalization API for low-latency profile lookups.
- Compliance
- GDPRCCPASOC 2 Type IIHIPAA support on qualifying plans
- Data residency
- Processing regions available including EU; data primarily remains in the customer's own warehouse.
- SSO
- SAML single sign-on with SCIM on enterprise plans.
- Security notes
- Because the warehouse remains the store of record and access is typically read-only, the vendor's data footprint is smaller than a traditional CDP's, which materially simplifies security review.
Support & resources
- Channels
- Email and ticket supportSlack-based support on higher tiersDedicated solution architects for enterprise
- Documentation
- Detailed technical documentation with destination-specific field mapping guides, aimed at analytics engineers.
- Community
- Strong presence in the modern data stack community, with published reference architectures and active participation in dbt and analytics engineering circles.
Company
- Founded
- 2018
- Headquarters
- San Francisco, California, United States
- Ownership
- Private, venture-backed
- Founders
- Tejas Manohar, Josh Curl, Kashish Gupta
- Employees
- ~300 (est. 2026)
- Funding
- Raised substantial venture funding including Series B and later rounds.
Timeline
- 2018Founded to solve reverse ETL, syncing warehouse data into business tools reliably.
- 2021Raises significant venture funding as the modern data stack consolidates around warehouse-native architecture.
- 2022Adds a visual audience builder, opening warehouse data to marketers without SQL.
- 2024Expands into journeys and personalization, positioning as a full composable CDP rather than a sync tool.
- 2025Introduces AI decisioning for per-customer message and offer selection measured against holdouts.
- 2026Established as a leading composable CDP for organizations with mature warehouses.
Integrations
- Snowflake
- BigQuery
- Databricks
- Redshift
- dbt
- Salesforce
- HubSpot
- Braze
- Klaviyo
- Meta Ads
- Google Ads
- Zendesk
Frequently asked questions
10 questionsWhat is Hightouch?
Hightouch is a composable customer data platform built on reverse ETL. It reads customer data already modelled in your cloud warehouse and syncs it into business tools such as CRM, email, advertising, and support platforms, so the warehouse remains the single source of truth rather than data being copied into a separate vendor store.
What is reverse ETL?
The practice of moving data out of a data warehouse into operational business tools, the opposite direction from traditional ETL which loads data into the warehouse. It exists because the most complete customer data usually ends up in the warehouse, while the people who need to act on it work in CRM, email, and ad platforms.
Do I need a data warehouse to use Hightouch?
Yes. It activates data rather than collecting it, so there must be a warehouse containing customer data to sync from. Companies without one need a collection-first CDP such as Segment or RudderStack, or a warehouse project first, before reverse ETL makes sense.
Hightouch vs Census: which is better?
They are closely matched. Census has traditionally been favored by data teams for its governance and dbt-centric modelling approach, while Hightouch has invested more heavily in marketer-facing audiences, journeys, and AI decisioning. Choose Census for a pure engineering-owned sync layer; choose Hightouch if business users should build audiences on warehouse data themselves.
How much does Hightouch cost?
There is a free tier for limited syncs and destinations. Paid plans are commonly several hundred dollars a month and are driven by destination count, sync frequency, and records activated, with the audience and decisioning layers priced above core reverse ETL and enterprise agreements quoted annually.
Does Hightouch store my customer data?
Not as a system of record. It reads from your warehouse and writes to destinations, holding operational metadata rather than becoming a parallel customer database. That architecture is the main reason security reviews go faster and switching costs stay low compared with a traditional CDP.
How real-time are the syncs?
Scheduled syncs run as frequently as your plan and warehouse allow, commonly every few minutes at the fastest, which suits most marketing and CRM use cases. Genuine request-time personalization requires the personalization API rather than a sync, since warehouse queries are not built for millisecond latency.
Will frequent syncs increase my warehouse bill?
Yes, and this is the cost people forget. Every sync run queries the warehouse, so hourly syncs on large models consume compute that appears on your Snowflake or BigQuery invoice rather than on the Hightouch one. Design models for incremental change detection and set frequency to what the use case actually needs.
Can marketers use Hightouch without SQL?
Yes, through the visual audience builder, which constructs queries against warehouse tables that a data team has prepared. The data team still governs which tables and fields are exposed, which is the arrangement most organizations want: self-serve for business users on top of models engineers control.
What happens if a sync fails?
Failures are reported at row level with reasons, so you can see exactly which records a destination rejected and why, with alerting into Slack, email, or PagerDuty. This is materially better than the silent partial failures typical of homegrown scripts, and it is one of the main practical arguments for buying rather than building.
Editorial verdict
Hightouch makes the strongest available case for the composable CDP: keep customer data where it is already governed, versioned, and correct, and treat activation as a sync problem rather than a storage problem. The engineering underneath, change detection, rate-limit handling, row-level error reporting, is exactly what teams underestimate when they decide to build it themselves, and configuration as code puts go-to-market plumbing under the same review process as the rest of the data stack. The prerequisites are unavoidable: no warehouse, no Hightouch, and no event collection either. Add the audience and decisioning layers and the price approaches a conventional CDP's. For data-mature teams it is close to the default choice, and for everyone else it is a reason to build the warehouse first.
Written by the SaaSTracker editorial team. Awards, when shown, are judged against the published criteria in our methodology.