Skip to main content
Product & Data

ETL (Extract, Transform, Load)

ETL — extract, transform, load — is the classic data-integration pattern: pull data from source systems, reshape it into the target schema, then load it into a warehouse. Its modern inversion, ELT, loads raw data first and transforms inside the warehouse, a shift made practical by cheap cloud storage and elastic compute.

The order flipped for economic reasons. Traditional ETL transformed on a dedicated server before loading, which required knowing the target schema up front and buying hardware sized for the transform workload. Cloud warehouses made storage nearly free and compute rentable by the minute, so the sensible sequence became: land the raw data, model it inside the warehouse, and keep the raw copy for whenever the logic changes.

ETL order is still correct in specific cases — personal data that must be masked before it may land anywhere, strict compliance boundaries, and legacy targets that cannot transform internally. Outside those, ELT is the default for warehouse-bound analytics, which is why the monolithic ETL suite gave way to a split stack: managed extract-and-load tools such as Fivetran or Airbyte, and in-warehouse transformation with dbt.

The engineering substance is the same whichever order you choose. Incremental extraction avoids re-reading entire source tables; deduplication handles the records that arrive twice; late-arriving data and slowly changing dimensions decide how history is represented; and every transformation carries tests, because an untested transform is a wrong number waiting for a board meeting.

ELT's convenience hides a cost that appears on the warehouse bill. Transforming after loading means every downstream model re-queries the raw tables, and teams that model carelessly pay to recompute the same joins thousands of times a day. Incremental models — processing only new or changed rows — and materialisation choices made with query costs in view are the difference between an elastic warehouse and an elastic invoice. Cheap storage does not make cheap computation; it just moves the bill.

Transformation logic is business logic and should be tested like it. Uniqueness and not-null checks catch structural breakage; accepted-value tests catch category drift; and a handful of reconciliations against source-system totals catch the subtle failures — the join that fans out, the filter that silently drops a region. Modern transform tooling makes these tests cheap to write, which removes the last excuse for shipping logic that has never been verified against a number someone trusts.

ETLELT
TransformsBefore loading, on separate infrastructureAfter loading, inside the warehouse
Raw data keptOften discardedYes — reprocessable when logic changes
Best whenPII masked pre-load; fixed target schemaCloud warehouse; evolving data models
Typical toolingInformatica, TalendFivetran / Airbyte + dbt

Codazz builds this in production — AI & ML Development.

FAQ

ETL (Extract, Transform, Load)
FAQ.

Common questions about etl (extract, transform, load).

Ask Us Anything

The monolithic ETL suite largely is; the pattern is not. Extracting, transforming and loading still describes most data movement — what changed is the order and the tooling. ELT with managed connectors and in-warehouse transformation covers the majority of new analytics builds, while ETL order persists where data must be transformed or masked before it is allowed to land.

Where and when transformation happens. ETL reshapes data before loading and typically discards the raw form; ELT loads raw data first and transforms it inside the warehouse, keeping the raw copy so models can be rebuilt when requirements change. ELT won the default because cloud warehouses made storing everything cheap and transforming on demand practical.

Managed connectors win for standard sources — databases and SaaS tools with popular APIs — because maintenance, schema drift and API changes become the vendor's problem. Build your own for proprietary systems, unusual protocols, or where connector pricing scales badly with your volume. The mistake is building what you could rent cheaply; the opposite mistake is forcing a managed tool to contort around a genuinely custom source.