Extract, Load, Transform definition
ELT (extract, load, transform) is a data integration approach that extracts data from sources, loads it in raw form into a cloud data warehouse or lakehouse, and transforms it there using the platform's own compute, typically with SQL. ELT keeps raw data available, simplifies ingestion and suits scalable platforms like Snowflake, BigQuery and Databricks.
How does ELT work?
In ELT, ingestion tools copy data from sources into the warehouse with minimal changes, landing it in raw or staging schemas. Transformations then run inside the warehouse as SQL models that clean, join and aggregate the raw tables into analytics-ready layers, often called staging, intermediate and marts. The warehouse's distributed compute does the heavy lifting, so there is no separate transformation server to size, patch and maintain.
Because raw data is preserved, analysts can create new models from historical data without re-extracting it from the source systems. If a transformation has a bug, engineers fix the SQL and rebuild the affected tables from the raw layer, which makes recovery far simpler than in traditional pipelines. It also lets several teams build their own models on the same raw data.
Why ELT became popular
Cloud data warehouses separate storage from compute and scale both on demand, making it practical to store large volumes of raw data and transform them in place. At the same time, managed connectors and SQL-based transformation tools made ELT accessible to analytics engineers rather than only specialist ETL developers. The typical ELT toolchain looks like the list below.
- Extract and load: Fivetran, Airbyte, Stitch or cloud-native connectors.
- Warehouse or lakehouse: Snowflake, BigQuery, Redshift, Databricks.
- Transform: dbt, Dataform or SQL scheduled by an orchestrator.
- Orchestration: Airflow, Dagster or the scheduler built into the tools.
- Testing and documentation: dbt tests, data contracts and catalogs.
ELT vs ETL
ETL transforms before loading, so only curated data enters the warehouse. ELT loads first and transforms later, keeping everything. ELT is faster to set up, more flexible for new questions and easier to debug. ETL is preferable when sensitive data must be removed before it reaches the warehouse, when the destination lacks compute power, or when complex processing suits a dedicated engine better than SQL. In practice, ELT is the default for new cloud analytics platforms.
ELT best practices
Organize models in clear layers with naming conventions, and keep transformations in version control with code review. Add tests for uniqueness, nulls, accepted values and relationships, and run them in CI before changes reach production. Use incremental models for large tables to control compute cost, and monitor warehouse spending closely, because transformation queries are billed by the platform.
Treat raw data carefully. Restrict access to raw schemas that may contain personal data, apply masking policies, and define retention rules so the lake of raw tables does not grow indefinitely. Document which raw tables hold sensitive fields, and review access regularly as teams and tools change.
Example of ELT
A SaaS company syncs its production PostgreSQL database, Stripe billing data and HubSpot CRM into Snowflake with a managed connector. dbt models combine them into tables for monthly recurring revenue, churn and customer health, tested and rebuilt every hour. Leadership dashboards in a BI tool read only the final marts. Nexzem sets up ELT stacks like this for growing companies that need trustworthy metrics quickly.