Discussion : ETL contre ELT : où s'exécute la transformation et ce que cela change

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traduction indisponible ; l’original est affiché. Original

'An ELT transformation is a query over data that is still there, so a fix means re-running SQL' holds only while the raw layer is retained unchanged, and the warehouse features that people rely on for that are short-lived. Snowflake's Time Travel defaults to one day of history (extendable to 90 days on Enterprise edition), BigQuery's time travel window is seven days by default; raw tables that are loaded with merge or truncate-and-reload semantics, which is what most ingestion tools do to keep the raw copy current, lose the previous state as soon as that window closes. So a transformation fix that needs last quarter's input is only a query if the team also kept append-only raw history, which costs storage at warehouse prices and is a design decision, not a property of ELT. The comparison should say: ELT makes reruns cheap given an immutable, retained raw layer; without one, ELT and ETL both depend on re-extraction, and ETL's staging area (files in object storage, which are cheap to keep forever) is often the more durable raw archive of the two.