Quick answer:
Reverse ETL copies data out of your warehouse and into the tools where people work: CRMs, ad platforms, email tools, support desks. Regular pipelines pour data into the warehouse; reverse ETL pumps the refined results back out, so the “customer lifetime value” your analysts computed shows up as a field in Salesforce instead of dying in a dashboard.
The name is a joke that stuck: it’s ETL pointed the other way.
What is reverse ETL?
By the early 2020s the standard stack had a strange dead end. Companies spent fortunes centralizing everything into Snowflake or BigQuery and modeling it beautifully with dbt.. and the output was dashboards. The sales rep in Salesforce, the marketer building an ad audience, the support agent in Zendesk never saw any of it, because none of them work in a BI tool.
Reverse ETL closes that loop. You point it at a modeled warehouse table (“all users with churn risk above 0.7”), map columns to fields in the destination, and the tool keeps the destination in sync, sending only what changed. The warehouse stops being a reporting archive and starts driving the systems where decisions get executed.
Who invented it?
The category formed around 2020 with 2 startups: Census and Hightouch, both betting the warehouse would become the center of gravity for customer data. It ended with an acquisition on one side and a rebrand on the other: Fivetran bought Census in May 2025 (so the biggest “into the warehouse” vendor now owns a major “out of the warehouse” product), while Hightouch raised $80M at a $1.2B valuation earlier that year and now leads with “data activation” and its composable CDP story, with reverse ETL as the plumbing underneath.
How is this different from a CDP?
A customer data platform (Segment, mParticle) collects events itself, keeps its own copy of your customer data, and syncs audiences to marketing tools from there. The reverse ETL argument: you already have a better copy, in the warehouse, with all your billing and product and support history joined together. Why maintain a second, worse one inside a vendor?
Built this way (warehouse as the store, reverse ETL as the delivery), the arrangement is called a composable CDP. The trade: you get every column your data team can model and one source of truth, but you also inherit the warehouse’s latency and your data team’s backlog. A packaged CDP is faster to stand up and opinionated about events; the composable version is more powerful and more DIY.
What do teams actually sync?
- Sales context: product usage scores, seats used, expansion signals pushed onto CRM records so reps stop selling blind.
- Ad audiences: high-LTV lookalikes and churn-risk suppression lists synced to Google and Meta (suppression alone often pays for the tool).
- Lifecycle email: warehouse-computed traits driving Braze, Klaviyo, or Iterable campaigns.
- Support triage: plan, spend, and health score visible on the ticket.
Notice the pattern: every one of these is a number that already existed in a dashboard, finally moved to where someone acts on it.
What are the gotchas?
Destination APIs are the ceiling. Ad platforms and CRMs rate-limit aggressively, so “real-time sync” quietly becomes “sync every hour when the API allows”. Costs need watching too: reverse ETL runs queries against your warehouse on a schedule, and destinations sometimes bill per record you push into them.
The deeper risk is organizational. Once Salesforce fields are fed by warehouse models, a broken dbt run stops being a stale dashboard and becomes wrong data in front of the sales team. Reverse ETL promotes your analytics pipeline to production infrastructure. Teams that adopt it without also adopting testing and observability discover this the loud way.
What are the benefits and drawbacks of reverse ETL?
Benefits of reverse ETL
Analytics finally reaches the people acting on it
The churn score leaves the dashboard and lands on the Salesforce record, in front of the rep, mid-call. The distance between “we know this” and “we do something about it” collapses to zero.
One model, every destination
Define “high-value customer” once in the warehouse and sync the same definition to ads, email, and support. The alternative is 5 tools each maintaining their own slightly wrong version.
Declarative sync beats custom scripts
Field mapping, diffing, retries, and API rate-limit handling come off the shelf. The pile of cron jobs calling the HubSpot API (every company has one) gets retired.
Suppression alone often pays the bill
Syncing “already converted” and “churn risk” lists to ad platforms stops money being spent on the wrong people. It’s the least glamorous use case and routinely the best ROI.
Drawbacks of reverse ETL
Your dbt bugs are now customer-facing
A broken model used to mean a stale chart; now it means wrong data in the CRM and emails sent to the wrong segment. The pipeline just got promoted to production, ready or not.
Destination APIs set the ceiling
Rate limits and quirky field APIs mean “real-time” quietly becomes “hourly, when the API allows”. The tool can only be as good as the door it’s pushing through.
Warehouse latency comes along for the ride
The sync is as fresh as the model behind it, which is as fresh as the load before that. Sum the chain before promising the marketing team anything.
Another meter starts running
Scheduled queries against the warehouse, per-row or per-destination pricing on the tool, and sometimes per-record charges at the destination. Three invoices for one arrow on the diagram.
Is it a feature or a category?
Increasingly a feature. Fivetran owns Census, warehouses keep growing native export paths, and every CDP now claims warehouse-native powers. Hightouch’s answer was to climb the stack toward AI-driven marketing decisioning rather than defend the pipe. For buyers this is all good news: the capability is table stakes now, and you should judge it by connector quality and observability, priced as plumbing rather than as a platform.