Reverse ETL

Everything so far has pointed one direction: ETL, ELT, and CDC all move data into the warehouse, where you model it, version it, and store it columnar. And there it sits — joined across every source, enriched with computed scores and segments, more complete than any single app’s database. The problem is who can act on it. A sales rep lives in Salesforce. A support agent lives in Zendesk. A marketer lives in the ad platforms. None of them work in your BI dashboard. Reverse ETL is the last mile: it syncs modeled data back out of the warehouse into the operational tools where people actually do their jobs.

The “last mile” problem

You build a beautiful churn-risk model. It joins product usage, support tickets, and billing into a single health_score per account — exactly what a Customer Success Manager needs. But it’s a column in a warehouse table. The CSM never opens the warehouse; they open Salesforce. So the score sits unused, and the company keeps churning customers it could have saved. This gap — great data on one side, the people who’d act on it on the other — is what reverse ETL (also called operational analytics or data activation) closes.

How a sync works

The shape is the mirror image of ETL. The warehouse is the source; a SaaS tool’s API is the destination. You:

1. Write a SELECT against a modeled table (often a “gold” table) — the rows and columns you want to push.
2. Map warehouse columns to the destination’s fields (health → Health_Score__c in Salesforce).
3. Sync — but as an idempotent upsert keyed by an external id, so re-running never duplicates; it overwrites the matching record in place.
4. Run incrementally — push only rows that changed since the last sync, to respect API rate limits.

Pick a destination and watch the same modeled rows take different operational shapes:

Notice three things in that widget. The mapping changes per destination (Salesforce wants Account fields; Slack wants a templated message). The sync is an upsert, not a dump — keyed by External_Id__c, so it’s safe to re-run. And incremental mode pushes only the changed rows, which is how you stay under an API’s request budget.

How it differs from ETL and CDC

That “destination is an API” row is the one that makes reverse ETL its own discipline. You can’t just INSERT into Salesforce — you call its REST API, which has rate limits, required fields, validation rules, and its own notion of identity. The dedicated tools (Hightouch, Census, and increasingly warehouse-native features) exist to handle exactly that: batching, retries, field mapping, and identity resolution against dozens of finicky APIs.

The hard parts

Reverse ETL’s difficulties come from the destination, not the SQL. Rate limits force batching and incremental syncs. Identity mapping is fiddly — which warehouse row is this Salesforce account? (hence the external-id key). Idempotency is non-negotiable because syncs retry. And observability matters more than in normal ETL: when a sync silently fails, a human downstream is now acting on stale data, so you need per-record success/failure reporting, not just “the job ran.”

Quick check

Next

You now have a full data platform: sources stream in via ETL and CDC, get modeled and stored columnar, and flow back out via reverse ETL. But all these jobs have to run — in the right order, on a schedule, recovering from failures. The system that coordinates them is an orchestrator. That’s the final piece, next.