ETL vs ELT & the Warehouse

ETL — extract, transform, load — was necessary when the warehouse was a fixed-size appliance. Transformation happened in a separate system, and only the modelled result landed. The problem is that raw data was discarded: when the definition of "active user" changed, you had to re-extract from the source, which may no longer hold the history.

ELT — extract, load, transform — lands raw data first and transforms it inside the warehouse with SQL. Cloud warehouses separate storage from compute and charge little for the former, so keeping everything raw is cheap. The consequence that matters: transformations become re-runnable, because the input is still there. A changed metric definition is a rebuild, not an archaeology project.

The stack in practice. Ingestion (Fivetran, Airbyte, or your own CDC) lands raw tables. dbt models transformations as version-controlled SQL with dependencies, tests and generated documentation — which is what turned analytics engineering into a software-engineering discipline, since models get reviewed, tested and deployed like code. Orchestration (Airflow, Dagster, Prefect) schedules and handles retries and dependencies. BI sits on top.

The layering convention is worth knowing because it appears in every dbt project: staging models clean and rename raw sources one-to-one; intermediate models join and reshape; marts are the business-facing tables analysts query. The point is that raw data is never queried directly and business definitions live in exactly one place.

Lakehouse formats — Iceberg, Delta Lake, Hudi — put table semantics (schema evolution, time travel, ACID-ish commits) over Parquet files in object storage, so warehouse-style querying works over a data lake. That is what has been collapsing the warehouse/lake distinction, and Iceberg in particular has become the interoperability format multiple engines read.

For a product engineer, the useful boundary is this: you own the quality and stability of the source data and the events you emit. If an event's shape changes silently, every downstream model breaks — which makes event schemas a contract, not an implementation detail.

You will not usually own the warehouse, but you will be asked to emit the events it consumes and to explain why a number in a dashboard disagrees with the product. Knowing where transformation happens and what a staging-to-mart pipeline looks like makes those conversations tractable, and "how do analytics get this data?" is a normal design follow-up.

• ELT keeps raw data, which makes transformations re-runnable when definitions change; ETL throws away that option.
• Cheap separated storage and compute in cloud warehouses are what made the reordering practical.
• dbt turns transformations into reviewed, tested, dependency-aware SQL — analytics as software engineering.
• The staging/intermediate/mart layering keeps business definitions in one place and raw tables out of reports.
• Orchestrators handle scheduling, dependencies and retries; they are not where logic should live.
• Lakehouse formats like Iceberg add schema evolution and time travel to files in object storage.
• Event schemas emitted by the product are a contract; changing one silently breaks every downstream model.