ELT stands for Extract, Load, Transform. Data is extracted from source systems, loaded into a cloud data warehouse in close to its original form, and only then transformed into modeled tables using the warehouse's own compute. It became the default approach once cloud warehouses made storage cheap and query engines fast enough to do the heavy transformation work in place.
How ELT works
The mechanics are the same three operations as ETL, moved into a different order and a different place. Because the transformation runs inside the warehouse rather than in a separate processing tier, the raw loaded data is still sitting there afterwards, and that is what makes a model reversible and a new question answerable without a new extract.
How it compares
ETL and ELT move the same data with the same three operations. What changes is where the transformation runs, and what survives it.
When your business needs one
- You are consolidating several source systems and the questions you will ask are still changing.
- A reporting change currently means asking someone to re-extract from the source.
- You are already on a cloud warehouse and paying for compute you are not using.
- You want analysts to be able to trace a number back to the raw record it came from.
- Your source systems are under load from repeated extracts for slightly different reports.
Benefits and limits
- The raw data stays in the warehouse, so a transformation can be corrected or re-cut without touching the source system.
- New questions can often be answered from data already loaded, rather than through a new integration project.
- Transformation is SQL, which far more people can read and review than a proprietary transformation tool.
- Load and transform are decoupled, so a failed model does not mean re-ingesting everything.
- You are storing raw data, so storage and compute costs are real and grow with retention.
- Loading first means personal or regulated data lands in the warehouse before it is filtered, which has to be handled with access controls and retention rules rather than assumed away.
- Without discipline the warehouse fills with raw tables and half-finished models. ELT shifts governance work rather than removing it.
- Transformations run on a schedule, so modeled tables lag the source by the length of that interval.
- ELT loads raw data into the warehouse first and transforms it there in SQL, reversing ETL's transform-then-load order.
- Its main advantage is reversibility: the raw data survives the model, so logic can change without a new extract.
- The trade-off is storage cost and governance, because the raw data has already landed and access and retention have to be managed deliberately.
Frequently Asked Questions
What is the difference between ETL and ELT?
The order of the last two steps, and where the transformation runs. ETL transforms data in a separate engine before loading it, and stores only the result. ELT loads the raw data into the warehouse first and transforms it there in SQL, keeping both the raw and the modeled versions.
Is ELT always better than ETL?
No. ELT suits cloud warehouses and changing requirements. ETL is still the right answer where data has to be filtered or masked before it can be stored at all, or where the destination cannot handle transformation workloads.
Does ELT need a data engineer?
It needs someone who can write SQL and think in models. Managed connectors have removed most of the custom code from the extract and load steps, but the transformation layer is still engineering work, even when the language is familiar.
Is ELT real-time?
Usually not. Both extraction and transformation run on a schedule, whether hourly, nightly or on a cron expression, so the modeled tables are only as fresh as the last run. True streaming is a different architecture.
Does BEEM use ELT?
Yes. BEEM connects to 750+ sources and loads them into a managed Amazon Redshift warehouse, where the raw tables are visible in the Datalake. Transformation happens afterwards in the Warehouse SQL editor, where each dataset is a query you preview, version and deploy on a schedule, with test assertions that can block a bad refresh.