On this page 11 sections

ETL and ELT are two ways of moving data from your business systems into one place for reporting. The difference is the order of the steps: ETL cleans and reshapes the data before loading it into its destination, while ELT loads the raw data first and cleans it inside the destination.
For most modern cloud data warehouses, ELT is the usual choice. ETL still wins when data must be cleaned or protected before it lands, or when the destination is too limited to do the heavy work. This guide compares both and shows how to choose.
Short answer
- ETL (extract, transform, load) cleans data before it reaches the destination.
- ELT (extract, load, transform) loads raw data first and cleans it in the destination.
- ELT suits cloud warehouses and lakehouses, and keeps raw data for reuse.
- ETL suits data that must be masked before loading, and limited destinations.
- Many businesses use both, chosen per data source.
What do ETL and ELT mean?
Both are data pipelines: automated jobs that copy data from where it is created, such as your accounting package, ERP, CRM or online shop, to where it is analysed, usually a data warehouse. There are three steps:
- Extract: copy the data out of the source system.
- Transform: clean and reshape it. Fix dates, remove duplicates, match "J Smith" with "John Smith", link sales to customers.
- Load: write the result into the destination. Microsoft puts it simply: ELT "differs from ETL solely in where the transformation takes place" (Microsoft Learn (opens in a new window)). Think of unpacking groceries: ETL sorts them in the car park, ELT sorts them in the pantry.
How ETL works
In ETL, data is transformed on a separate server or tool before it is loaded. AWS describes this as transforming data "on a secondary processing server" (AWS (opens in a new window)). The data arrives ready to use.
Strengths
It works best with structured data that fits a predefined layout (IBM (opens in a new window)).
Sensitive details, such as personal information, can be masked before they reach the destination (IBM (opens in a new window)).
It suits older databases and destinations with limited processing power (AWS (opens in a new window), Microsoft Learn (opens in a new window)). Weaknesses
It needs an extra server or tool to build and maintain.
It can slow down as data grows, because everything waits for the transform step (AWS (opens in a new window)).
Pipelines often need re-engineering when sources or requirements change (IBM (opens in a new window)).
How ELT works
In ELT, the pipeline "loads data as it is and transforms it at a later stage" (AWS (opens in a new window)). The destination does the cleaning, usually with SQL. That removes the separate transformation server, and scaling the destination also scales the pipeline (Microsoft Learn (opens in a new window)).
Keeping the raw data gives a more complete historical record (Google Cloud (opens in a new window)). If a rule changes, you rebuild from the raw copy instead of extracting again.
On Databricks, ELT is often organised as the medallion pattern. A bronze layer holds raw data as it arrived, silver holds cleaned and validated data, and gold holds refined tables for reports. Databricks calls this a recommended best practice, not a requirement (Databricks docs (opens in a new window)). Our Databricks consulting page has more.
ELT has costs too. Google lists raw data that may contain personal information, complex logic that needs skilled people, "data swamps" if the store isn't managed, and quality checks needed after loading (Google Cloud (opens in a new window)).
ETL vs ELT side by side
| ETL | ELT | |
|---|---|---|
| When data is cleaned | Before loading | After loading |
| Where it is cleaned | A separate server or tool | Inside the destination |
| Raw data in the destination | Not by default | Yes, kept for reuse |
| Best with | Structured data in a set layout | Structured, semi-structured and unstructured data |
| Time to first load | Slower, waits for cleaning | Faster, loads straight away |
| Sensitive data | Can be masked before it lands | Needs access controls once it lands |
| Upfront cost | Higher: extra infrastructure and engineering | Lower, but costs can grow with data volume |
| Upkeep | Often re-engineered when sources change | Simpler stack, usually less upkeep |
| Typical destination | Older or limited databases, regulated data | Cloud warehouses and lakehouses |
Sources: IBM (opens in a new window), AWS (opens in a new window), Microsoft Learn (opens in a new window), Google Cloud (opens in a new window).
When to choose ETL or ELT
Choose ELT when
- Your destination is a modern cloud warehouse or lakehouse with elastic compute (Microsoft Learn (opens in a new window)).
- You want to keep raw data for later questions you haven't thought of yet.
- Your data is a mix of tables, files and documents.
- You want to change business rules without a new extraction. Google says, "In general, we recommend the ELT approach to most customers" for BigQuery (BigQuery docs (opens in a new window)). That is one vendor's advice for its own product, so treat it as a hint, not a rule.
Choose ETL when
- Data must be standardised or protected before it reaches the destination, for example regulated data (IBM (opens in a new window)).
- You work with older systems or a destination that is too constrained to do heavy transformations (AWS (opens in a new window), Microsoft Learn (opens in a new window)).
- Sensor or IoT data should be filtered before it goes to the cloud (AWS (opens in a new window)).
Can you use both?
Yes. Google notes that a hybrid approach, using ELT and ETL for different parts of the pipeline, may also be used (Google Cloud (opens in a new window)). A common pattern is a small ETL step that drops or masks sensitive columns, then ELT for everything else.
ETL, ELT and POPIA
ELT keeps raw copies, and raw data often includes personal information, so it is a POPIA question as well as a technical one. This is general information, not legal advice.
- Take only what you need. POPIA section 10 says personal information may only be processed if, given the purpose, it is "adequate, relevant and not excessive" (POPIA s10 (opens in a new window)). If a report doesn't need ID numbers or card details, mask or drop them before loading.
- Set a retention period for raw data. Section 14 says records must not be kept longer than necessary, unless an exception applies such as a legal requirement, a lawful business need, a contract or consent. Once you may no longer keep a record, it must be destroyed, deleted or de-identified (POPIA s14 (opens in a new window)).
- Limit who sees the raw layer. In the medallion pattern, bronze is mainly used by data engineers, operations and compliance teams, while business users work with gold (Databricks docs (opens in a new window)).
A simple example
This is an illustrative example, not a client project. A business has an accounting package, an online shop and a stock spreadsheet, and wants monthly sales by product.
- With ELT: a nightly job copies all three sources into the warehouse unchanged, and SQL builds the "sales by product by month" table. If finance changes the definition of "net sales", you change the SQL and rebuild from the raw data.
- With ETL: a script cleans product codes, removes customer ID numbers and loads only the finished table. If the definition changes, you update the script and may need to pull the old data again.
Common mistakes
- Loading everything "just in case". That is how a data store becomes a swamp, and it adds POPIA risk.
- Skipping quality checks after loading. ELT moves cleaning later, so add tests at that point.
- No monitoring. A pipeline that fails silently gives you old numbers that look current. Set alerts on failed or late loads.
Which should you choose?
| Your situation | A sensible approach |
|---|---|
| Cloud warehouse or lakehouse, mixed data, you want raw history | ELT |
| Data with ID numbers or card details that reports don't need | A small ETL step to drop or mask them, then ELT |
| Older on-premise database, limited destination, or sensor data to filter first | ETL |
| One main system and a few reports | Neither yet. Use that system's reports, and read the signs you've outgrown Excel |
| Not sure | A short review of your systems and reports before choosing anything |
How Mammoth Digital can help
Our team works with Databricks, SQL Server and PostgreSQL, and includes a Databricks Certified Data Engineer Professional. We can map where your data lives, recommend ETL, ELT or a mix for each source, and build and monitor the pipelines.
See our Databases & Data services or contact us to talk through your reporting.
Databricks is a trademark of Databricks, Inc., BigQuery of Google LLC and SQL Server of Microsoft Corporation. Mammoth Digital is independent and not a partner of these companies.
Facts checked on 9 November 2026. Sources: AWS, Google Cloud, Microsoft Learn, IBM, Databricks, POPIA s10, POPIA s14.