# ETL vs ELT > ETL transforms data before loading it into the analytical destination; ELT loads source data first and transforms it inside that destination. Choose ETL when data must be filtered, standardized, or reduced before arrival, and ELT when you need flexible analysis and can govern retained source data safely. Source: https://sysround.com/compare/etl-vs-elt Updated: 2026-11-05 ## Side by side | | ETL | ELT | |---|---|---| | Processing order | Extract, transform, load | Extract, load, transform | | Transformation compute | Separate processing layer before destination | Destination warehouse or lakehouse compute | | Data initially loaded | Cleaned, filtered, or aggregated data | Source-shaped data, often minimally processed | | New analytical requirements | May require pipeline changes and re-extraction | Can rebuild models from retained source data | | Sensitive data | Can remove it before destination loading | Requires controls over raw landing areas | | Cost drivers | Processing layer plus destination usage | Raw retention plus destination transformations | | Freshness | Transformation precedes destination availability | Raw arrival precedes curated availability | | Failure recovery | Replay staged inputs or re-extract | Rerun transformations over retained inputs | ## The differences that matter The architectural boundary is where transformation runs, not whether the pipeline uses SQL or scheduled jobs. An ETL design might normalize events in processing workers before loading reporting tables. An ELT design loads those events into a warehouse or lakehouse, then uses its compute to build reporting tables. ELT preserves options when future questions are unknown. Retaining source-shaped events lets you change session definitions, fix parsing bugs, or add dimensions without extracting everything again. ETL can also retain raw inputs in a separate staging store, so replayability depends on retention and architecture, not just the acronym. ETL can enforce a destination boundary: remove personal fields, reject invalid records, or aggregate detailed events before loading. ELT puts more responsibility on the raw landing area, including access restrictions, retention limits, and deletion workflows. A practical hybrid removes prohibited fields before loading, then performs analytical transformations inside the destination. Neither approach is automatically cheaper or faster. ETL can reduce loaded volume but requires upstream processing capacity. ELT can reuse scalable analytical compute, but repeated scans, large joins, and backfills can compete with dashboards. Compare total processing, storage, and operational cost under the expected workload. ETL versus ELT is separate from batch versus streaming. Both can run incrementally, and both need explicit handling for duplicates, late events, schema changes, and partial failures. In an interview, distinguish raw-data arrival latency from the time when validated, queryable results become available. ## Choose ETL when - Sensitive fields must not enter the analytical destination, even in a restricted raw layer. - Consumers need a narrow, stable schema, and transformation rules are well understood. - Filtering or aggregation can substantially reduce destination ingestion and storage. - Transformations need specialized processing that the destination cannot support efficiently. ## Choose ELT when - Analysts need to explore source detail and frequently change derived models. - Historical data must be reprocessed when business definitions or transformation logic change. - The warehouse or lakehouse supports the required transformations with suitable workload isolation. - Many downstream models share the same source data, and a governed raw layer can support them. ## Worked example: Changing session rules in a web analytics pipeline Assume a web analytics service receives 100 million events per day, averaging 1 KB each, or roughly 100 GB before compression. Dashboards need curated results within five minutes. With ELT, the service loads privacy-filtered events into a restricted raw layer, then builds session and conversion tables incrementally. If the session timeout changes from 30 to 45 minutes, retained events allow a historical rebuild. With ETL that loads only session aggregates, that rebuild requires separately retained event-level inputs or re-extraction. If policy forbids storing IP addresses in the destination, remove them before loading under either design. Run historical rebuilds separately from the compute serving fresh dashboards. ## In the interview - Start with the destination, required outputs, freshness target, and data restrictions. Explain where transformation belongs because of those constraints, rather than naming a preferred tool. - Estimate source volume, retained raw history, and transformation scan volume. Expect questions about whether filtering early saves more than retaining raw data enables. - Describe retry-safe loading and publication: stable event identifiers, deduplication or merge rules, checkpoints, and atomic publication of completed outputs. - Separate the ingestion freshness target from the curated-data freshness target. Explain how late events update previously published results. - Expect a backfill probe: identify retained inputs, version transformation logic, isolate backfill compute, and explain how corrected outputs replace old results without double counting. ## Common mistakes - Equating ETL with batch and ELT with real time. Execution cadence is a separate design choice. - Assuming ELT means unrestricted raw-data storage. Privacy, access control, retention, and deletion still apply. - Claiming ETL cannot replay data or ELT always makes replay easy. Both depend on retained inputs, reproducible logic, and safe output writes. - Comparing only ingestion speed or compute price while ignoring curated-data freshness, storage, backfills, and dashboard contention. ## Interview questions where it comes up - [Design Google Analytics](https://sysround.com/questions/design-google-analytics): The choice determines where events become sessions and aggregates, and whether retained detail supports corrected historical analysis. - [Design an ad click aggregator](https://sysround.com/questions/design-ad-click-aggregator): It shapes the boundary between event ingestion, validated billing aggregates, and historical reconciliation. - [Design an A/B testing platform](https://sysround.com/questions/design-ab-testing-platform): Exposure and outcome data need reproducible transformations so attribution changes can be applied to retained history. - [Design a large data migration to the cloud](https://sysround.com/questions/design-cloud-data-migration): When source and target schemas differ, transformation placement affects transfer volume, staging needs, and validation. ## FAQ ### What is the main difference between ETL and ELT? ETL transforms extracted data before loading it into the analytical destination. ELT loads source-shaped data first and transforms it using the destination's compute. The distinction affects governance, retained detail, compute placement, and recovery. ### Is ELT faster and cheaper than ETL? Not necessarily. ELT can make raw data available sooner, but useful reporting data still waits for transformations. Cost depends on data reduction, retained history, scan frequency, compute pricing, and workload isolation. ### Can ETL and ELT be used together? Yes. A pipeline can validate records and remove sensitive fields before loading, then join, aggregate, and build analytical models inside the destination. Explain which transformations happen on each side of the loading boundary and why. ## Related concepts - [Data lakes and warehouses](https://sysround.com/concepts/data-lake) - [Columnar storage](https://sysround.com/concepts/columnar-storage) - [Change data capture](https://sysround.com/concepts/change-data-capture) - [Schema evolution](https://sysround.com/concepts/schema-evolution) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.