Data Replication vs ETL: What Is the Difference?

Data replication copies data from one system to another and keeps the copy in step with the source. ETL extracts data, reshapes it under business rules, and loads the result into a new home. Replication preserves shape and ETL changes it. As of October 2026 most analytics teams replicate first and transform inside the warehouse, the pattern called ELT, keeping classic ETL for data that must change before it lands.

What does data replication actually do?

Replication copies data objects and their later changes so a second system holds the same rows as the first. The PostgreSQL manual separates the two forms in one sentence. “We use the term logical in contrast to physical replication, which uses exact block addresses and byte-by-byte replication.”

The replica can trail the source or hold it back, and the PostgreSQL high availability chapter settles it in one line. “Asynchronous communication is used when synchronous would be too slow.” MySQL adds a semisynchronous middle ground.

Change data capture, or CDC, is how replication crosses engine boundaries. AWS DMS reads “the database logs using the database engine’s native API,” and Debezium lists the payoff. It “Requires no changes to your data model” and “Can capture deletes.” The native Postgres setup is three statements, per the quick setup page.

-- postgresql.conf on the publisher
wal_level = logical

-- on the publisher
CREATE PUBLICATION mypub FOR TABLE users, departments;

-- on the subscriber
CREATE SUBSCRIPTION mysub
  CONNECTION 'dbname=foo host=bar user=repuser'

-- postgresql.conf on the publisher
wal_level = logical

-- on the publisher
CREATE PUBLICATION mypub FOR TABLE users, departments;

-- on the subscriber
CREATE SUBSCRIPTION mysub
  CONNECTION 'dbname=foo host=bar user=repuser'

-- postgresql.conf on the publisher
wal_level = logical

-- on the publisher
CREATE PUBLICATION mypub FOR TABLE users, departments;

-- on the subscriber
CREATE SUBSCRIPTION mysub
  CONNECTION 'dbname=foo host=bar user=repuser'

Notice what is missing. No field list, no rules, no target model. SQL Server states the constraint outright, “the Subscriber must contain tables with the same schema and data as the tables at the Publisher.”

What does ETL actually do?

ETL pulls data from several sources, changes it to fit a target model under business rules, and loads the finished shape. AWS says it “uses a set of business rules to clean and organize raw data.” Informatica states the goal, “to make all data fit within a uniform schema.”

The transform is the whole point and the whole cost. Oracle calls it “by far the most complex in the ETL process.” Whether the engine is Spark before the load or SQL after it, a transform looks like this dbt model.

with customer_orders as (
    select
        customer_id,
        min(order_date) as first_order_date,
        count(order_id) as number_of_orders
    from jaffle_shop.orders
    group by 1
)
select
    customers.customer_id,
    customers.first_name,
    customer_orders.first_order_date,
    coalesce(customer_orders.number_of_orders, 0) as number_of_orders
from jaffle_shop.customers
left join customer_orders using (customer_id)

with customer_orders as (
    select
        customer_id,
        min(order_date) as first_order_date,
        count(order_id) as number_of_orders
    from jaffle_shop.orders
    group by 1
)
select
    customers.customer_id,
    customers.first_name,
    customer_orders.first_order_date,
    coalesce(customer_orders.number_of_orders, 0) as number_of_orders
from jaffle_shop.customers
left join customer_orders using (customer_id)

with customer_orders as (
    select
        customer_id,
        min(order_date) as first_order_date,
        count(order_id) as number_of_orders
    from jaffle_shop.orders
    group by 1
)
select
    customers.customer_id,
    customers.first_name,
    customer_orders.first_order_date,
    coalesce(customer_orders.number_of_orders, 0) as number_of_orders
from jaffle_shop.customers
left join customer_orders using (customer_id)

That customers table exists nowhere in the source. Someone designed it for a question, and that is the whole difference.

How is data replication different from ETL?

Replication answers to the source and ETL answers to the consumer. A replicated table is correct when it matches the source row for row, which a count or a checksum proves, as the guide to data integrity verification shows. A transformed table is correct when it matches a business definition, which only a test on the output proves.

The industry blurs the line, often on purpose. Oracle sells GoldenGate as a way to “replicate, filter, and transform data,” per its documentation. PeerDB’s README calls a log-based CDC product “an ETL/ELT tool built for PostgreSQL.” The names drift, the test above does not.

Is ELT just replication plus a warehouse?

Mostly, yes. ELT lands raw rows that mirror the source and runs the transform inside the warehouse afterward. Microsoft’s architecture guide says ELT “differs from ETL solely in where the transformation takes place.” AWS now calls ELT “the standard choice for modern analytics.”

The load half of ELT is replication by another name. Fivetran’s core concepts describe it as “extract and load the raw data into the destination, then transform it post-load.” Zero-ETL is the same move with a marketing budget. AWS announced its “zero-ETL future” on November 29, 2022, and the Redshift documentation says the integration “replicates data from the source to the target data warehouse.”

Reverse ETL is the same pattern pointed back at operational tools.

Where replication and ETL go wrong

Replication breaks when the source changes shape or values cross engines, and ETL breaks when the rules are wrong and the raw data is gone.

Schema changes stop the copy

PostgreSQL logical replication does not carry DDL. The restrictions page says “The database schema and DDL commands are not replicated.” When new rows no longer fit, “replication will error until the schema is updated.” Google Datastream warns that dropping a column from the middle of a table can leave values attached to the wrong column.

Types drift between engines

Heterogeneous replication is a quiet transform. AWS DMS documents older versions converting the value 0.611111104488373 to 0.611111 under a default precision mapping. Fivetran says “we may need to transform a source data type to a supported destination data type.”

Rules hide and raw data vanishes

An ETL job that aggregates before loading throws away the rows it summarized. Fivetran describes the old pattern as pipelines “that pre-aggregated and filtered data down to a consumable size.” dbt’s viewpoint holds that “Any code that generates data or analysis should be reviewed and tested,” which needs the raw layer intact.

Which tools support data replication and change data capture, and which run ETL?

Tools supporting data replication and change data capture read a database log and apply the changes elsewhere. Debezium, AWS DMS, Google Datastream, Qlik Replicate, Striim, and native Postgres and MySQL replication do that. Fivetran, Airbyte, and dlt load raw tables for warehouse SQL, and dbt, Spark, Informatica, and Matillion transform.

Debezium captures every delete without touching the data model, and skips updates and deletes on tables with no primary key, per its Postgres connector docs. AWS DMS runs “fully heterogeneous data migrations between the supported engines,” per its user guide, and its CDC “does not provide real-time replication.”

Fivetran delivers a cleaned schema at the lowest level of aggregation and meters every distinct row each month, with a free plan that stops at 500,000 monthly active rows. Airbyte runs free at any scale under the Elastic License, which forbids reselling it as a managed service. dbt moves nothing, since every model “is a select statement.”

When to replicate, when to transform, and when to do both

Replicate when the target must mirror the source, transform when the consumer needs a shape no source holds, and in a warehouse do both in that order.

Filament by Galaxy handles both jobs. It replicates with full, incremental, and change data capture reads, and its in-pipeline transformations rename, drop, and compute columns before the sink writes, which covers the masking case above. It never joins, filters rows, or aggregates, so a joined model still belongs in the warehouse. The Postgres connectors are beta and most others alpha. Disclosure, this site belongs to Galaxy, the company behind Filament.

The honest case for classic ETL is narrow but real. AWS writes that ETL fits “legacy databases or third-party data sources with predetermined data formats.” Everywhere else, keep the raw rows, because a transform you cannot rerun is a decision you cannot undo.

Related guides

• What is change data capture, the complete guide

• Full load vs incremental vs CDC, which to use

• Postgres logical replication, the complete guide

• Append vs replace vs upsert, write modes explained

• Change streams vs triggers vs polling

• Database replication, the complete guide

Frequently asked questions

What is data replication?

Data replication copies data from one system to another so both hold the same rows, then delivers later changes so the copy stays current. The target keeps the source’s shape. Databases ship it natively, and change data capture tools do the same job across engines.

Is data replication the same as ETL?

No. Replication copies data as it is and keeps the copy current, while ETL changes data under business rules and loads a new shape. The quick test is whether the target table exists in the source. If it does, you are replicating. If it is a join or an aggregate no source holds, you are transforming.

What is the difference between ETL and ELT?

Only where the transform runs. ETL changes data in a separate engine before loading it, so the warehouse never sees the raw rows. ELT loads the raw rows first and transforms them in the warehouse with SQL. Microsoft’s architecture guide says the two differ solely in where transformation happens.

Is ETL outdated?

Transform-before-load is no longer the default for analytics, but it is not dead. Cloud warehouses made it cheap to land raw data and transform it in place, so most new pipelines are ELT. ETL still fits legacy sources with fixed formats, data masked before storage, and targets that cannot run SQL.

Can data replication and ETL work together?

Yes, and most warehouse stacks do exactly that. A replication or change data capture tool lands raw tables that mirror the source, then SQL models transform them into the shapes analysts query. The raw layer is the replication and the modeling layer is the transform.

Is log-based change data capture faster than batch ETL?

For freshness, yes. A log reader sees a committed change within milliseconds on MySQL or PostgreSQL, according to Debezium’s documentation, while a batch job waits for its schedule. For a one-time load a bulk copy is usually faster, which is why replication tools snapshot first and then stream.

Does change data capture put load on the source database?

Less than query-based polling, but not zero. A log reader never scans tables, so it avoids repeated SELECT statements. The database still writes extra detail into its log and holds that log until every reader consumes it. PostgreSQL warns that an idle replication slot can retain enough log to fill the disk.

Does replication handle schema changes automatically?

Rarely in full. PostgreSQL logical replication does not replicate DDL, so a new column must be added on the subscriber by hand before rows carrying it arrive. Managed services handle some changes and not others. Google Datastream says dropping a column from the middle of a table or changing its type can cause data discrepancies.

What is zero-ETL, and is it really zero?

Zero-ETL is a vendor term for a managed integration that copies an operational database into a warehouse without a pipeline you build. It is replication under a new name. AWS’s own documentation says that after an initial data load, the integration replicates data from the source to the target. The transform moves into the warehouse.