What Is ETL? ETL vs ELT Explained, with Examples

ETL stands for extract, transform, load. It is the process of taking data out of the systems where it is created, reshaping it into a form that is useful for analysis, and writing it into a system built for analysis. Almost every report, dashboard and machine-learning model in a company sits on top of an ETL process, whether anyone calls it that or not.

This guide defines the terms, explains the difference between ETL and ELT, and shows what a working pipeline looks like.

The three steps

Extract reads data from a source. Sources are databases such as PostgreSQL or SQL Server, files on object storage such as S3, and the APIs of business applications such as Salesforce, Stripe or Workday. Extraction has to decide what to read: everything, or only what changed since the last run.

Transform turns raw records into something consistent. Typical transformations are cleaning values, converting types, joining records from different sources, deduplicating, masking personal data, and computing derived fields such as a margin or a customer segment.

Load writes the result into the destination: a data warehouse, a lakehouse, an operational database, or sometimes a file that another system picks up.

A pipeline is the set of these steps for one business purpose, run on a schedule or triggered by an event. "Orders from the shop database, joined with refunds from Stripe, loaded into the finance schema every hour" is a pipeline.

ETL vs ELT

The difference is only the order of the last two letters, but it changes where the work happens.

ETL transforms first. The pipeline reads the source, applies the logic, and loads only the finished result. This is the right shape when data must be cleaned or masked before it reaches the destination, when the destination has little compute of its own, or when the output is an operational system rather than an analytics store.

ELT loads first. Raw data lands in the warehouse, and the transformation is done there in SQL, often with a modeling tool. This became popular with cloud warehouses because they have elastic compute, and because keeping raw data allows the logic to be rerun later. Its cost is that raw data, including anything sensitive, now sits in the destination, and the warehouse bill grows with every transformation.

In practice most teams do both. A pipeline might mask customer identifiers during extraction (ETL), land the masked rows as a raw table, and build reporting tables from them in SQL (ELT). The useful question is not "which letter order" but "where does each piece of logic belong, and what does it cost to run there".

A worked example

A retailer wants a daily table of net revenue by product.

1. Extract orders from PostgreSQL, reading only rows updated since yesterday, and refunds from Stripe over its API.
2. Transform by joining refunds to their orders, converting currencies, dropping test orders, and summing net revenue per product per day.
3. Load the result into the finance.daily_net_revenue table in the warehouse, replacing yesterday's partition.
4. Check that the row count and the total are within the expected range before the table is published to dashboards.

The fourth step is not in the acronym, and it is the one most teams add after their first bad number reaches a board pack. A pipeline that validates its own output and records what ran is the difference between a script and a system.

What makes ETL hard

The happy path is easy. The hard parts are the second run and the bad day:

• Incremental loads. Reading only what changed requires a reliable cursor, such as an updated-at column or a database change log, and handling late-arriving or deleted rows.
• Re-runs. When a run fails halfway, rerunning it must not duplicate rows. Idempotent loads and per-step resume are what make that safe.
• Backfills. Reprocessing a month of history should produce the same tables a normal run would, without a one-off script.
• Schema change. A column renamed upstream should fail loudly, not silently load nulls for a week.
• Evidence. When someone asks which inputs produced a figure, the answer should be a record, not a reconstruction.

Tools differ far more on these than on the basic three steps.

Where Revoluzen Flow fits

Revoluzen Flow is an open-source ETL and orchestration tool that runs on your own machines. Pipelines are built on a visual canvas or written as SQL and Python steps in the same graph, scheduled, and run with per-step resume, idempotent backfills and a run history detailed enough to answer questions later. It connects to 66 systems, of which 57 are in the open-source build, and it installs with one command:

pip install revoluzen-flow && revoluzen open

For a comparison with hosted services, see replacing hosted ELT.

Frequently asked questions

Is ETL the same as a data pipeline?

Not quite. ETL describes what the work is: extract, transform, load. A data pipeline is the implementation of that work for one purpose, with a schedule, dependencies and error handling. Pipelines can also do things that are not ETL, such as triggering a report or calling an API.

Is ELT replacing ETL?

No. ELT fits cloud warehouses with spare compute and teams that prefer SQL. ETL remains necessary when data must be masked or reduced before it reaches the destination, when the destination is an operational system, or when the warehouse bill makes in-warehouse transformation expensive. Most organizations run both.

What is the difference between ETL and data integration?

Data integration is the broader goal of making data from different systems usable together. ETL is one technique for achieving it, alongside replication, change data capture, APIs and virtualization.

Do I need a separate orchestration tool for ETL?

Only if your pipeline tool cannot schedule, order and retry work on its own. Some tools only move data and rely on an external scheduler; others, including Revoluzen Flow, combine the two. See what is data pipeline orchestration.

How much data does ETL need before it is worth a tool?

The volume matters less than the number of sources and the cost of a wrong number. One source and one script are fine until the script fails at two in the morning or a figure reaches a regulator. A tool earns its place when reruns, monitoring and evidence stop being optional.