Why Reverse ETL Tools Shouldn't Exist

Reverse ETL tools exist because pipelines are incomplete.

They solve a problem that shouldn’t be there in the first place.

The Problem

Most data stacks look like this:

• Ingestion → Airbyte
• Transformation → dbt
• Storage → Snowflake
• Activation → Census / Hightouch

Every layer is a different tool.

And when you want to send data out of your warehouse — into Salesforce, HubSpot, or an API — you need to add another system.

That system is reverse ETL.

What Reverse ETL Tools Actually Do

At their core, reverse ETL tools do three things:

1. Select data from a table
2. Detect what changed
3. Send it to an API

That’s it.

The Abstraction Is Wrong

Reverse ETL tools are built as separate products.

But they don’t introduce a new concept.

They reuse existing ones:

• SQL queries
• HTTP requests
• change detection

So why is this a separate system?

The Real Reason They Exist

Because your pipeline stops too early.

Most tools end at:

“data is now in a table”

But that’s not the end of the job.

The real job is:

“data is used somewhere”

What Should Exist Instead

Reverse ETL is not a product.

It’s a direction.

Forward:

external → database

Reverse:

database → external

Same pipeline. Different direction.

A Simpler Model

A reverse ETL job is just a model:

# models/sync/users.star
# @kind: tracked
# @unique_key: id

rows = query("SELECT id, email, plan FROM mart.customers")
for row in rows:
    http.post("https://api.example.com/users", json=row)
    save.row(row)

Query. Send. Track. That’s the entire system.

Change Detection Is Not a Product

Reverse ETL tools add:

• snapshot tables
• diff engines
• sync state

But change detection is just:

“did this row change?”

That can be solved directly:

• content hashing
• identity tracking
• deterministic comparison

No separate system required.

The Cost of Getting It Wrong

Reverse ETL tools introduce:

• another system to operate
• another pricing model (per row, per sync)
• another layer of failure
• another place where state can break

And most of the logic is duplicated:

• filters
• mappings
• transformations

Already written elsewhere.

What Happens When You Remove the Layer

When reverse ETL becomes part of the pipeline:

• you use the same SQL
• you use the same runtime
• you reuse the same state
• you eliminate an entire system

There is no “sync job”.

There is just a model.

The Key Idea

If your pipeline can read data, it should also be able to write it.

Anything else is an artificial limitation.

This Changes the Stack

Instead of:

• pipeline → warehouse → reverse ETL → API

You get:

• pipeline → API

No middle system. No duplication.

What You Actually Need

Three primitives:

• Query data
• Detect changes
• Send data

That’s it.

Everything else is packaging.

One Line

Reverse ETL tools exist because pipelines were designed to stop too early.