ETL vs. ELT — woran du erkennst, welches Muster du wirklich gebaut hast

Veröffentlicht 24.06.2026
von

„Wir machen ETL.“ Der Satz fällt in fast jedem Daten-Team — und stimmt oft nicht. Wenn jede Transformation als Stored Procedure läuft, nachdem die Rohdaten bereits unverändert in eine Staging-Tabelle geladen wurden, dann ist das der Sache nach ELT. Das Etikett verdeckt, was wirklich passiert. Der Unterschied ETL vs. ELT entscheidet sich nicht an der Reihenfolge der Buchstaben, sondern daran, wo die Transformation rechnet — und ob roh zuerst geladen wird.

TL;DR — was dieser Artikel zeigt:

  • Was E, T und L wirklich sind — drei logische Phasen, die in jedem Datenintegrations-Ansatz vorkommen. Die Buchstaben-Reihenfolge allein entscheidet nichts.
  • Der Zwei-Kriterien-Test — wo läuft die Transform-Compute, und wird roh zuerst geladen? Damit lässt sich jede Pipeline als ETL oder ELT einordnen.
  • In-flight vs. Push-down — der eigentliche Trennstrich, mit T-SQL- und Postgres-Beispiel.
  • Das „ETL-Pattern“ dieser Serie eingeordnet — architektonisch ist es persistent-staging-ELT (mit einem ehrlichen Hybrid-Vorbehalt am finalen Load).
  • Die Familie — ELT, EtLT, Medallion, Data Vault — und wann ETL trotzdem die richtige Wahl bleibt.

Voraussetzung. Grundverständnis von ETL und Datenintegration. Konzeptueller Einordnungs-Artikel, kein Schritt-für-Schritt-Tutorial. SQL Server und Postgres dienen als Beispiel-Engines; die Code-Snippets sind illustrativ und machen den Unterschied sichtbar, sie bauen kein lauffähiges Schema auf.

Inhalt

ETL vs. ELT: Was E, T und L wirklich sind

Extract, Transform, Load — drei Buchstaben, drei Aufgaben. Daten aus einer Quelle holen, sie in die gewünschte Form bringen, sie ins Ziel schreiben. Diese drei Phasen sind logisch und kommen in jedem Datenintegrations-Ansatz vor. Auch eine ELT-Pipeline extrahiert, transformiert und lädt. Was ETL und ELT trennt, ist nicht die Existenz dieser Phasen, sondern ihre physische Anordnung und der Ort ihrer Ausführung.

Hier liegt das erste Missverständnis: Das Akronym beschreibt nicht die Logik, sondern das Ausführungsmodell. „ETL“ heißt, dass die Transformation vor dem Laden ins Ziel passiert — typischerweise in einer eigenen Tool-Engine, die die Daten unterwegs verarbeitet. „ELT“ heißt, dass roh zuerst geladen wird und die Transformation danach im Ziel- oder Staging-Engine läuft, meist als SQL.

Das zweite Missverständnis ist generationell: ETL gilt als „alt“, ELT als „modern und Cloud“. Das ist Marketing, kein Architektur-Argument. ELT ist keine Erfindung der Cloud-Anbieter — ein roher Load in eine Staging-Tabelle, gefolgt von SQL-Transformation, ist eine Technik, die so alt ist wie das Data Warehouse selbst. Cloud-Plattformen wie Snowflake oder BigQuery (gemanagte Analyse-Datenbanken mit enormer SQL-Rechenleistung) haben ELT nur populär gemacht, weil ihre Engine die Transformation günstig und parallel erledigt. Die Unterscheidung bleibt aber architektonisch: Sie hängt daran, wo die Compute läuft, nicht daran, in welchem Jahrzehnt oder auf welcher Plattform.

Der Test: zwei Kriterien

Statt am Akronym zu kleben, klassifiziert man eine Pipeline mit zwei Fragen:

  1. Wo läuft die Transform-Compute? In einer separaten Pipeline-/Tool-Engine, die die Zeilen durchschleust (in-flight) — oder als SQL im Ziel-/Staging-Engine, nachdem die Daten dort liegen (push-down)?
  2. Wird roh zuerst geladen? Landet zuerst eine unveränderte Roh-Kopie in einer persistenten Zwischenschicht (load-raw-then-transform) — oder wird die Zeile transformiert, bevor sie irgendwo geschrieben wird (transform-then-load)?

Die beiden Antworten laufen meist parallel: In-flight-Transformation geht mit transform-then-load zusammen (= ETL), Push-down mit load-raw-then-transform (= ELT). Wenn sie auseinanderlaufen — etwa eine leichte Bereinigung im Datenfluss, der Rest per SQL nach dem Load — landet man im Zwischenfeld, das später als EtLT auftaucht.

Die folgenden zwei Snippets machen den Unterschied an demselben Mini-Fall sichtbar: eine CSV mit Kundenname, Betrag und Land-Text soll in eine Zieltabelle, dabei wird der Betrag typisiert und das Land auf einen Schlüssel gemappt.

In-flight: die ETL-Signatur

In einem grafischen ETL-Tool wie SSIS hängt die Transformation im Datenfluss, zwischen Quelle und Ziel. Jede Zeile wird im Arbeitsspeicher des Tools konvertiert, getrimmt und nachgeschlagen — und erst die fertige Zeile wird ins Ziel geschrieben:

CSV-Quelle
  │
  ├─ Data Conversion : betrag (Text -> decimal)
  ├─ Derived Column  : TRIM(name)
  ├─ Lookup          : land_text -> land_id
  │     (alle Transformationen laufen IM Tool-Datenfluss, im Arbeitsspeicher)
  ▼
OLE-DB-Ziel : dwh.kunde   <- erst hier wird geschrieben

Transform vor Load, Compute in der Tool-Engine — das ist die klassische ETL-Signatur. Der Data-Flow-Designer ist nicht copy-paste-SQL, deshalb steht hier ein Schaubild statt eines Statements.

Der In-flight-Ansatz hat eine organisatorische Kehrseite, die man im Tool-Alltag ständig sieht: Weil das Werkzeug pro Zieltabelle einen Datenfluss anlegt, baut der nahe liegende Reflex ein Paket pro Tabelle — und jedes Paket bündelt Extraktion, Transformation und Laden für genau diese eine Tabelle. Ein Prozess besteht dann aus vielen gleichartigen Paketen hintereinander, jedes macht für seine Tabelle dasselbe. Das ist tool-getrieben gedacht, nicht prozess-getrieben.

Der mengen-basierte Gegenentwurf dreht die Achse: nicht pro Tabelle E+T+L, sondern pro Phase alle Tabellen — erst alles extrahieren, dann alles transformieren und prüfen, dann alles laden. Jede Phase ist eine Mengen-Operation im DB-Engine statt einer Schleife über Tabellen-Pakete. Genau diese mengen-basierte Transform- und Prüf-Phase ist der Kern des Push-down-Modells — und der Grund, warum sich Datenqualität dort generisch und an einer Stelle prüfen lässt, statt verstreut in jedem einzelnen Tabellen-Paket.

Push-down: die ELT-Signatur

Push-down dreht die Reihenfolge um: Erst landet die Roh-Zeile unverändert in einer Staging-Tabelle (Spalten als Text), dann transformiert ein SQL-Statement sie im Engine. In T-SQL:

  1: -- 1) Roh laden: nichts wird unterwegs transformiert
  2: INSERT INTO staging.kunde_raw
  3: (
  4:     name
  5:    ,betrag
  6:    ,land_text
  7: )
  8: SELECT
  9:     name
 10:    ,betrag
 11:    ,land_text
 12: FROM
 13:    OPENROWSET(BULK N'kunde.csv', FORMATFILE = N'kunde.fmt') T01(name, betrag, land_text);
 14:
 15: -- 2) Erst im Ziel-Engine transformieren: Typisierung nach dem Load
 16: INSERT INTO dwh.kunde
 17: (
 18:     name
 19:    ,betrag
 20:    ,land_id
 21: )
 22: SELECT
 23:     TRIM(T01.name)
 24:    ,TRY_CONVERT(decimal(12, 2), T01.betrag)  -- ungueltig wird NULL, kein Abbruch
 25:    ,T02.land_id
 26: FROM
 27:    staging.kunde_raw T01
 28:    LEFT JOIN dim.land T02
 29:    ON
 30:      T02.land_text = T01.land_text;

Dasselbe Muster in Postgres — COPY lädt roh in text-Spalten, die Transformation folgt per SQL:

  1: -- 1) Roh laden: COPY in text-Spalten, keine Transformation
  2: COPY staging.kunde_raw
  3: (
  4:     name
  5:    ,betrag
  6:    ,land_text
  7: )
  8: FROM '/import/kunde.csv' WITH (FORMAT csv, HEADER true);
  9:
 10: -- 2) Erst im Engine transformieren: Cast + Lookup per SQL nach dem Load
 11: INSERT INTO dwh.kunde
 12: (
 13:     name
 14:    ,betrag
 15:    ,land_id
 16: )
 17: SELECT
 18:     TRIM(T01.name)
 19:    ,T01.betrag::numeric(12, 2)  -- in Produktion abgesichert, siehe DQ-Reihe
 20:    ,T02.land_id
 21: FROM
 22:    staging.kunde_raw T01
 23:    LEFT JOIN dim.land T02
 24:    ON
 25:      T02.land_text = T01.land_text;

Roh zuerst (das L), Transformation per SQL im Engine danach (das T) — das ist die ELT-Signatur. In beiden Snippets liegt die Transform-Compute dort, wo auch die Daten liegen; das Tool, das die CSV bewegt hat, war nur ein Loader. Die Typisierung ist hier illustrativ verkürzt: In der Praxis wird der Cast abgesichert (TRY_CONVERT statt hartem Cast, in Postgres eine geprüfte Variante), damit ein ungültiger Wert den Lauf nicht abbricht — genau das ist das Thema der TRY_CONVERT-Reihe und der sicheren Typ-Konvertierung weiter unten.

Eingeordnet: das „ETL-Pattern“ dieser Serie ist ELT

Wendet man den Zwei-Kriterien-Test auf das in dieser Serie ausgearbeitete ETL-Design-Pattern an, fällt das Urteil eindeutig aus. Das Pattern schichtet den Prozess in Arbeitspakete mit eigenen Datenbankschemata (E0–L2):

  • Roh-Landing in Schema E1. Daten aus Textdateien werden zunächst als nvarchar materialisiert — keine Typisierung bei der Extraktion. Das ist load-raw-then-transform in Reinform.
  • Typisierung und Datenqualität in T1. Erst danach konvertieren generische Stored Procedures die Werte in die Zieldatentypen und prüfen die technische Datenqualität — per SQL, im Engine, nach dem Load; die historisierte Fortschreibung dieser Daten liegt in T2.
  • Strukturelle Transformation in L1. Fremdschlüssel-Auflösung und Lookups laufen als SQL-SELECT mit JOINs über die gestagten Tabellen; die Historisierung dieser Stufe liegt in L2.
  • SSIS nur als EL-Mover. Das ETL-Tool bewegt Dateien und materialisiert sie in E0/E1 — die Transformations-Substanz liegt in T-SQL.

Beide Test-Kriterien zeigen also auf ELT: Roh wird zuerst geladen, und die Transform-Compute läuft als SQL im Engine. Genauer: persistent-staging-ELT — jede Zwischenstufe wird materialisiert und bleibt für Audit und Wiederanlauf erhalten. Und genau das ist der Grund, warum das Pattern robust, wiederanlaufbar und auditierbar ist: Schlechte Daten werden an den Schema-Grenzen isoliert, statt einen In-flight-Datenfluss zum Abbruch zu bringen.

Das ist keine Korrektur der Cluster-Marke. Der Bestands-Cluster heißt zu Recht „ETL-Prozess“: Das Akronym benennt die drei logischen Phasen, die der Prozess durchläuft, und die sind unstrittig vorhanden. Was hier präzisiert wird, ist das Ausführungsmodell dahinter — und das ist ELT. Akronym und Ausführungsmodell sind zwei verschiedene Ebenen; beide dürfen nebeneinander stehen.

Ehrlich bleiben beim Verdikt. Das Pattern ist nicht rein ELT. Sein finaler Schritt — das Laden in das Zielsystem — ist je nach Ziel wieder ETL-artig: Geht es in eine SQL-Datenbank, bleibt es Push-down (INSERT/UPDATE). Geht es dagegen über eine API in ein Nicht-DB-Ziel wie Dynamics 365 (in der Architektur-Beschreibung ausdrücklich erwähnt), braucht es wieder ein ETL-Tool, das die Zeilen in API-Calls übersetzt. Sauber gesagt: ein Hybrid mit ELT-Schwerpunkt — die Schwerarbeit (Typisierung, DQ, strukturelle Transformation) ist push-down, der letzte Meter zum Nicht-DB-Ziel kann in-flight sein.

ELT, EtLT und die Medallion-Verwandtschaft

Hat man eine Pipeline einmal als ELT identifiziert, lässt sie sich in eine größere Familie einordnen. Die gemeinsame Klammer: roh zuerst laden, dann in mehreren Schichten transformieren (multi-hop, persistentes Staging).

  • Medallion-Architektur. Der in der Cloud-Welt (Databricks, Lakehouse) verbreitete Bronze-/Silver-/Gold-Aufbau folgt demselben Prinzip: Bronze = rohe Landing-Daten, Silver = bereinigt/typisiert, Gold = geschäftsfertig. Grob auf das Serien-Pattern gemappt: Bronze ≈ E1, Silver ≈ T1/T2, Gold ≈ L1/L2 — mit der Einschränkung, dass „Gold“ oft zusätzlich aggregierte Marts meint, während die Aggregation im Serien-Pattern ein separater, nachgelagerter Schritt ist. Gleiches Muster, andere Vokabeln.
  • Data Vault. Fachlicher Schlüssel, Hash-basierte Delta-Erkennung und die Schichtung Raw/Cleansed/Business sind eng verwandt — die Architektur-FAQ ordnet das Pattern bereits als „leichteres“ Data-Vault-Geschwister ein.
  • EtLT. Das kleine „t“ steht für eine leichte Bereinigung schon beim Laden (Trimmen, Encoding, offensichtlicher Schrott), während die fachliche Schwerarbeit (großes „T“) weiterhin push-down im Engine passiert. Genau der Fall, in dem die zwei Test-Kriterien auseinanderlaufen.

Auf der Tool-Seite ist dbt (ein SQL-zentriertes Transform-Framework mit Versionierung und Tests) das heute prägende ELT-Werkzeug: Es transformiert ausschließlich nach dem Load, im Ziel-Engine — push-down per Definition. Wer also dbt auf Snowflake, BigQuery oder Postgres fährt, macht ELT, ganz gleich, wie das Projekt intern heißt.

Wann ETL, wann ELT — der praktische Entscheid

Die Einordnung ist kein Selbstzweck — sie hilft bei der Wahl. ELT ist heute der Default, wenn Ziel oder Staging eine fähige SQL-Engine ist und Push-down plus Auditierbarkeit gewünscht sind. Das gilt für jedes relationale Data Warehouse, für Postgres ebenso wie für SQL Server, und erst recht für die Cloud-Analyse-Plattformen, deren Engine genau dafür gebaut ist.

ETL — Transformation vor dem Load, in einer eigenen Engine — bleibt aber die richtige Wahl in drei Konstellationen:

  • Das Ziel ist keine fähige SQL-Engine. Schreibt die Pipeline über eine API in ein Nicht-DB-Ziel (Dynamics 365, ein SaaS-CRM, ein Message-Bus), gibt es kein „Engine“, in das man push-down transformieren könnte. Die Transformation muss vorher passieren — der finale Load des Serien-Patterns ist genau dieser Fall.
  • Daten müssen vor dem Landen transformiert werden. Compliance-Gründe wie PII-Masking oder Pseudonymisierung können verlangen, dass sensible Rohwerte gar nicht erst persistent in einer Staging-Schicht liegen. Dann muss die (zumindest maskierende) Transformation in-flight passieren.
  • Die Transform-Engine ist der Integrationspunkt. Wenn ein ETL-Tool als zentrale Drehscheibe viele heterogene Quellen und Ziele verbindet und seine Konnektor- und Buffer-Stärken ausspielt, kann es sinnvoll sein, die Transformation dort zu bündeln, statt sie in eine Ziel-Datenbank zu verlagern.

Wo die Entscheidung konkret zwischen SSIS und reinem T-SQL fällt — also die Mikro-Ebene derselben Frage —, vertieft der Artikel SSIS vs. SQL das mit drei Entscheidungs-Kriterien. Die pragmatische Synthese dort ist übrigens ein hübscher Beleg für diesen Artikel: SSIS als Orchestrierungs-Wrapper, die SQL-Substanz in Stored Procedures — das ist genau die ELT-Bauweise, das Tool als Mover, die Transformation push-down.

Eine Grenze noch: Der Zwei-Kriterien-Test ist bewusst batch-orientiert. Continuous- und Streaming-Pipelines (Change Data Capture, Kafka, Flink) verwischen die Trennung — dort wird die ETL-vs-ELT-Frage zu einer eigenen Diskussion, die dieser Artikel nicht führt.

FAQ

Ist ELT einfach ein neues Wort für ETL?

Nein. Beide enthalten dieselben drei logischen Phasen (Extract, Transform, Load), aber sie unterscheiden sich im Ausführungsmodell: ETL transformiert vor dem Laden in einer separaten Engine, ELT lädt roh zuerst und transformiert danach per SQL im Ziel- oder Staging-Engine. Es ist ein architektonischer Unterschied, kein Umbenennen.

Mein ETL-Tool transformiert im Datenfluss — ist das ETL?

Ja. Wenn die Zeilen im Arbeitsspeicher des Tools konvertiert, bereinigt und nachgeschlagen werden und erst die fertige Zeile ins Ziel geschrieben wird, ist das die klassische In-flight-Signatur — Transform vor Load, Compute in der Tool-Engine. Das ist ETL, unabhängig davon, wie modern das Tool ist.

Ist mein SSIS-Paket ETL oder ELT?

Das kommt auf die Bauweise an — SSIS ist nicht per se ETL. Steckt die Transformations-Logik in Data-Flow-Komponenten (Derived Column, Lookup, Data Conversion), ist es ETL. Bewegt das Paket dagegen nur Dateien in eine Staging-Tabelle und ruft danach Stored Procedures auf, die per SQL transformieren, ist es ELT — dasselbe Tool, anderes Ausführungsmodell.

Gilt die Unterscheidung auch für Postgres oder ganz ohne Cloud?

Ja, vollständig. Der Zwei-Kriterien-Test ist plattform-neutral. Ein COPY in eine text-Staging-Tabelle, gefolgt von SQL-Transformation, ist ELT auf Postgres — ohne jede Cloud. Umgekehrt kann eine On-Prem-Pipeline mit In-flight-Tool-Transformation klassisches ETL sein. ELT ist kein Cloud-Feature, sondern eine Frage, wo die Compute läuft.

Was ist EtLT?

EtLT ist der Mischfall: ein kleines „t“ für eine leichte Bereinigung schon beim Laden (Trimmen, Encoding-Korrekturen, offensichtlicher Schrott), während die eigentliche fachliche Transformation (großes „T“) weiterhin push-down im Engine nach dem Load passiert. Es beschreibt Pipelines, bei denen die beiden Test-Kriterien nicht sauber zusammenfallen.

Wo ordnen sich Data Vault und die Medallion-Architektur ein?

Beide sind Ausprägungen von ELT mit persistentem, mehrschichtigem Staging. Die Medallion-Schichten Bronze/Silver/Gold entsprechen grob den Schema-Schichten E1 / T1–T2 / L1–L2 des Serien-Patterns. Data Vault teilt fachlichen Schlüssel, Hash-Delta-Erkennung und die Raw/Cleansed/Business-Trennung, ist aber strenger und schwerer — das Serien-Pattern ist das pragmatischere Geschwister.

Verwandte Artikel

ETL-Design-Pattern-Cluster — der durchgearbeitete Fall, der hier eingeordnet wird:

SSIS-vs-SQL-Cluster — dieselbe Frage auf der Tool-Mikro-Ebene:

Das „T“ im Detail — die TRY_CONVERT-Reihe als push-down-Bausteine: