What Is ELT and How Does It Differ from ETL?

Updated

ELT stands for Extract, Load, Transform: data is pulled from source systems, loaded in raw form into a target data warehouse or lakehouse, and only then transformed inside that target system. It differs from ETL mainly in sequencing—ETL transforms data before it reaches the warehouse, while ELT uses the warehouse's own compute to do the work after loading. ELT tends to fit organizations running scalable cloud warehouses that need to land large volumes of raw data quickly and keep transformation logic close to the data; ETL remains a reasonable fit when transformation must happen before data enters a governed target or when the target system has limited compute.

How ELT works, step by step

  1. Extract. Connectors read data from sources—applications, databases, APIs, files. Informatica, for example, describes connecting and moving data across clouds, apps, and databases with 300+ connectors in one pipeline.
  2. Load. The extracted data lands in the target warehouse largely as-is, often in raw or staging tables. Loading first preserves the original detail, so transformations can be re-run without re-extracting from source.
  3. Transform. SQL or the warehouse's native compute cleans, joins, aggregates, and models the data into reporting-ready tables. Because transformation runs where the data sits, there is no separate transformation server to size and maintain.

The expected result is a pipeline where raw data is available quickly and business logic is expressed as transformations inside the warehouse—versionable, re-runnable, and auditable.

ELT vs. ETL: the same dimensions, side by side

Dimension ETL ELT
Order of operations Transform before load Load before transform
Where transformation runs Separate ETL engine or server Target warehouse or lakehouse compute
Raw data in the target Typically not retained Usually retained in staging/raw layers
Scaling model Scales with the ETL engine's capacity Scales with the warehouse's compute
Re-processing Often requires re-extraction Can re-run transformations on stored raw data
Governance and quality Enforced in the pipeline before load Must be designed into post-load layers and checks
Typical fit Constrained targets, strict pre-load controls Elastic cloud warehouses, high raw data volumes

When ELT is the better choice

ELT is generally preferable when:

  • The target is an elastic cloud warehouse. Compute can be scaled up for heavy transformations and down afterward, so transformation load doesn't require a separate fleet of servers.
  • Raw data volumes are large and growing. Loading first avoids building transformation capacity sized for peak volume before you know what the data contains.
  • Transformation logic changes often. Keeping raw data in the warehouse lets teams revise models without going back to source systems.
  • Multiple teams need the same raw data. Analysts, data scientists, and downstream pipelines can each transform it differently.

ETL is often the better choice when the target system cannot handle transformation workloads, when data must be masked or filtered before it is allowed to land, or when existing ETL investment and skills are working well.

Trade-offs to plan for

  • Reliance on target-system compute. Transformation performance and cost now depend on the warehouse. Poorly written transformations can consume significant compute, so workload management and query tuning matter.
  • Governance and data quality move downstream. With raw data landing first, access controls, masking, and quality checks must be built into the layers above it. Informatica positions data quality and observability—automatic profiling, cleaning, and monitoring—and governance as separate capabilities alongside integration, which reflects this need.
  • Cost visibility. Because storage and compute are consumed inside the warehouse, ELT costs are spread across storage of raw layers and transformation compute. Track both rather than assuming ELT is cheaper.
  • Duplicate or stale raw layers. Without retention rules, staging areas accumulate. Define how long raw data stays and which layers are authoritative.

Where ELT fits in a broader data platform

ELT is one pattern inside data integration and cloud data management, not a standalone product category. Informatica's platform page groups data integration (connect and move data across every cloud, app, and database), data quality and observability, governance, enterprise catalog, and master data management as related services. In practice, an ELT pipeline depends on ingestion connectors, a governed target with cataloged lineage, and quality checks on the transformed output—so evaluate ELT tooling by how well it connects to those surrounding capabilities, not just by whether it can load data.

To decide: confirm your target warehouse can absorb transformation compute, map which data must be masked before landing, and check that lineage and quality monitoring cover the post-load layers. If all three hold, ELT is usually the simpler operating model; if any fails, a pre-load ETL step for that data is the safer route.