---
title: "Reverse ETL"
description: "Reverse ETL is the process of syncing curated data from a data warehouse back out into operational tools like a CRM, ad platform, or support desk, so business teams can act on it."
canonical: "https://motherduck.com/glossary/reverse-etl/"
related:
  - title: "Reverse ETL | MotherDuck Docs"
    url: "https://motherduck.com/docs/integrations/reverse-etl/"
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "E-Commerce Data Teams: Drive Revenue with LLMs | MotherDuck | MotherDuck"
    url: "https://motherduck.com/videos/ecommerce-data-teams-llms-revenue/"
---

# Reverse ETL

> Reverse ETL is the process of syncing curated data from a data warehouse back out into operational tools like a CRM, ad platform, or support desk, so business teams can act on it.

## Overview

Traditional ETL (extract, transform, load) moves data from operational systems—like a CRM or application database—into a warehouse for analysis. Reverse ETL runs in the opposite direction: it takes modeled, cleaned data that already lives in the warehouse and pushes it back out into the SaaS tools that sales, marketing, and support teams use every day.

The motivation is that a warehouse is where the most trustworthy, joined-up view of a customer usually lives—combining product usage, billing, support tickets, and marketing touches—but that view is useless to a sales rep unless it shows up inside Salesforce, or to a marketer unless it shows up as an audience in an ad platform. Reverse ETL closes that loop.

<glossary-callout video="agentic-data-engineering-pipelines-ai" />

## How it fits in the stack

A typical reverse ETL flow looks like:

1. Raw data lands in the warehouse from application databases, event trackers, and third-party APIs (regular ETL/ELT).
2. Analytics engineers model that data—often with dbt—into clean, business-defined tables (e.g., a `customer_health_score` table, or a `product_qualified_leads` table).
3. A reverse ETL tool (Hightouch, Census, or similar) queries that modeled table on a schedule and syncs each row to a destination system, mapping columns to fields in that system's API (e.g., a warehouse column becomes a Salesforce custom field or a HubSpot contact property).

This makes the warehouse a single source of truth that both feeds dashboards *and* drives operational workflows, instead of maintaining separate, potentially inconsistent logic in each downstream tool.

## Example

A `customer_health_score` model, built and scheduled in the warehouse, might combine login frequency, support ticket volume, and contract value:

```sql
CREATE OR REPLACE TABLE customer_health_score AS
SELECT
    customer_id,
    login_count_30d,
    open_support_tickets,
    contract_value,
    CASE
        WHEN login_count_30d = 0 AND open_support_tickets > 2 THEN 'at_risk'
        WHEN login_count_30d > 20 THEN 'healthy'
        ELSE 'neutral'
    END AS health_status
FROM customer_metrics;
```

A reverse ETL tool then syncs `health_status` into a custom field on the Account object in the CRM, so account managers see it without needing warehouse access.

## The DuckDB angle

DuckDB is increasingly used as the warehouse or transformation engine that sits upstream of reverse ETL: teams build and test the modeling logic locally or in MotherDuck, then point a reverse ETL tool at the resulting tables. Because reverse ETL tools generally connect over standard SQL interfaces, any DuckDB-backed warehouse that exposes a compatible connection can serve as a source, the same as a cloud data warehouse would.