ELT (Extract, Load, Transform) und ETL (Extract, Transform, Load) unterscheiden sich grundlegend darin, wann und wo Datentransformationen stattfinden. Bei ETL verarbeitet eine externe Middleware die Daten, bevor sie ins Zielsystem gelangen. Bei ELT landen Rohdaten zuerst im Warehouse, die Transformation folgt danach mit der Rechenleistung des Warehouses selbst. Für die meisten modernen Cloud-Architekturen ist ELT heute der bevorzugte Ansatz, weil er schnelleren Datenzugriff und mehr Flexibilität bietet. Der Markt für Datenpipeline-Tools wächst bis 2030 auf ca. 48,33 Mrd. USD, wobei ELT gegenüber ETL deutlich an Bedeutung gewinnt. Welcher Ansatz für Ihr Unternehmen passt, hängt von Infrastruktur, Governance und Teamstruktur ab.
1. Wie ELT und ETL technisch funktionieren
ELT und ETL folgen denselben drei Phasen, aber in unterschiedlicher Reihenfolge. Das ist kein Detail. Es verändert die gesamte Architektur.
Bei ETL extrahiert ein Prozess Daten aus Quellsystemen, transformiert sie in einer dedizierten Middleware oder einem Staging-Server und lädt das Ergebnis dann ins Ziel-Warehouse. Die Transformation findet also außerhalb des Warehouses statt, auf separater Infrastruktur. Das bedeutet: Das Warehouse erhält bereits bereinigte, strukturierte Daten.
Bei ELT werden Rohdaten zuerst direkt ins Warehouse geladen. Die Transformation läuft danach innerhalb des Warehouses, mit dessen eigener Rechenleistung. SQL-basierte Transformationstools wie dbt (data build tool) sind für dieses Muster gebaut. Das Warehouse übernimmt die Arbeit, die früher externe Server geleistet haben.
Ein zentraler technischer Unterschied betrifft das Schema. ETL arbeitet nach dem Prinzip Schema-on-Write: Die Datenstruktur wird vor dem Laden definiert. ELT nutzt Schema-on-Read: Die Struktur entsteht erst bei der Abfrage oder Transformation. Schema-on-Read macht ELT agiler bei Änderungen, weil Rohdaten nicht neu extrahiert werden müssen, wenn sich Anforderungen ändern.
| Merkmal | ETL | ELT |
|---|---|---|
| Transformationsort | Externe Middleware | Im Warehouse |
| Schemaansatz | Schema-on-Write | Schema-on-Read |
| Rohdaten im Warehouse | Nein | Ja |
| Flexibilität bei Änderungen | Gering | Hoch |
| Typische Infrastruktur | On-Premise, Legacy | Cloud-Warehouse |
Profi-Tipp: Prüfen Sie, ob Ihre Transformationen wirklich im Warehouse laufen. Viele als ELT bezeichnete Pipelines sind eigentlich ineffizientes ETL, weil die Transformationslogik außerhalb des Warehouses implementiert wurde.
2. Vorteile von ELT für Cloud-Datenarchitekturen
ELT ist für Cloud-Warehouses wie BigQuery, Snowflake oder Redshift konzipiert. Diese Plattformen skalieren Rechenleistung elastisch, was ETL-typische Engpässe auf externen Transformationsservern überflüssig macht.
Der erste Vorteil ist Geschwindigkeit beim Datenzugriff. ELT ermöglicht schnelleren Zugriff auf Rohdaten und erleichtert Ad-hoc-Analysen, weil Analysten direkt auf unverarbeitete Daten zugreifen können, ohne auf abgeschlossene Transformationsjobs zu warten. Das beschleunigt iterative Modellentwicklung erheblich.
Dazu kommt die Kostenstruktur. Cloud-Warehouses berechnen Rechenleistung nach Verbrauch. Transformationen im Warehouse kosten nur dann, wenn sie laufen. Separate ETL-Server laufen dagegen oft rund um die Uhr, unabhängig von der tatsächlichen Last.
ELT bewahrt außerdem die vollständige Datenhistorie. Weil Rohdaten im Warehouse verbleiben, können Transformationsmodelle jederzeit neu berechnet werden, ohne Daten erneut zu extrahieren. Das ist ein konkreter Vorteil für Audits und Fehleranalysen.
Für Analytics-Teams mit SQL-Kenntnissen passt ELT besonders gut. ELT verbessert Team-Workflows durch Versionskontrolle und schnelle Iterationen mit SQL, was Änderungen an Analysemodellen ohne Eingriff in die Extraktionsschicht ermöglicht.
- Rohdaten sofort verfügbar für explorative Analysen
- Transformationslogik in SQL versionierbar und testbar
- Keine separate Transformationsinfrastruktur notwendig
- Iterative Modellentwicklung ohne erneute Extraktion
- Elastische Skalierung der Rechenleistung im Warehouse
Profi-Tipp: Setzen Sie dbt (data build tool) für Transformationen im Warehouse ein. dbt bringt Softwareentwicklungspraktiken wie Tests, Dokumentation und Versionskontrolle direkt in SQL-basierte ELT-Pipelines.
3. Wann ETL weiterhin die bessere Wahl ist
ETL ist nicht veraltet. Es gibt Szenarien, in denen ETL klar überlegen ist, und IT-Manager sollten diese kennen.
Das stärkste Argument für ETL ist Datenschutz und Compliance. ETL eignet sich besser für stark regulierte Umgebungen mit Pseudonymisierung vor dem Laden und für Legacy-Systeme mit begrenzter Rechenleistung im Ziel. Wenn personenbezogene Daten nach DSGVO vor dem Eintritt ins Warehouse anonymisiert oder pseudonymisiert werden müssen, ist ETL der sicherere Weg. Die Transformation findet außerhalb des Warehouses statt, sensible Rohdaten gelangen gar nicht erst ins Zielsystem.
Legacy-Systeme sind ein weiterer Grund. Viele Schweizer Unternehmen betreiben On-Premise-Datenbanken oder ERP-Systeme, die keine elastische Rechenleistung bieten. Ein Cloud-Warehouse ist dort nicht vorhanden oder nicht erreichbar. ETL mit externer Transformationsinfrastruktur ist dann die einzige praktikable Option.
Bandbreitenbeschränkungen spielen ebenfalls eine Rolle. Wenn Rohdaten sehr groß sind und die Netzwerkverbindung zum Warehouse begrenzt ist, reduziert ETL das Datenvolumen vor dem Transfer. Das spart Übertragungszeit und Kosten.
- Pseudonymisierung und Anonymisierung vor dem Laden (DSGVO)
- On-Premise-Infrastruktur ohne Cloud-Warehouse
- Geringe Bandbreite zwischen Quelle und Ziel
- Kleine, stabile Datenmengen mit fester Transformationslogik
- Komplexe Transformationen, die keine SQL-Implementierung erlauben
Profi-Tipp: Wenn Ihr Unternehmen mit Gesundheitsdaten oder Finanzdaten arbeitet, prüfen Sie vor der Architekturentscheidung, welche Daten das Warehouse überhaupt erreichen dürfen. In manchen Fällen schreibt die Compliance ETL vor.
4. Mischformen: EtLT als pragmatischer Mittelweg
Die Wahl zwischen ELT und ETL ist selten absolut. In der Praxis hat sich ein hybrider Ansatz etabliert, der als EtLT bezeichnet wird.
Hybride EtLT-Ansätze kombinieren leichte Bereinigungen beim Laden mit komplexen SQL-Transformationen im Warehouse. Das kleine „t" steht für eine minimale Transformation vor dem Laden: Deduplizierung, Zeichensatzbereinigung, Entfernung offensichtlich fehlerhafter Zeilen. Die eigentliche fachliche Transformation folgt danach im Warehouse.
Dieser Ansatz löst ein reales Problem. Rohdaten aus externen APIs oder Legacy-Systemen sind oft so unstrukturiert, dass sie das Warehouse beschädigen würden, wenn sie unbereinigt geladen werden. Eine leichte Vorverarbeitung schützt die Datenqualität, ohne die Flexibilität von ELT aufzugeben.
Persistent Staging ist dabei ein entscheidendes Architekturmuster. Persistent Staging erhöht Robustheit und Auditierbarkeit, isoliert fehlerhafte Daten und ermöglicht einen einfachen Fehler-Reset. Statt Rohdaten nach der Transformation zu verwerfen, bleiben sie in einer Staging-Schicht erhalten. Wenn ein Transformationsjob fehlschlägt, kann er neu gestartet werden, ohne Daten erneut zu extrahieren.
| Ansatz | Transformationsort | Typischer Einsatz |
|---|---|---|
| ETL | Externe Middleware | Compliance, Legacy, On-Premise |
| ELT | Im Warehouse | Cloud, Ad-hoc-Analyse, SQL-Teams |
| EtLT | Beides kombiniert | Unreine Quellen, gemischte Anforderungen |
Ein Risiko bei ELT ohne Governance ist unkontrolliertes Datenwachstum. Wenn alle Rohdaten ungefiltert ins Warehouse fließen, entstehen schnell unübersichtliche Datenmengen ohne klare Verantwortlichkeit. Persistent Staging und klare Schichtenarchitektur (Bronze, Silber, Gold) beugen dem vor.
5. Compliance und Governance in ELT-Umgebungen
ELT bringt spezifische Governance-Anforderungen mit sich, die ETL-Umgebungen so nicht kennen. Das liegt daran, dass Rohdaten zuerst geladen werden, bevor jede Bereinigung stattfindet.
Compliance bei ELT erfordert Maskierung, restriktive Zugriffe und Governance auf Spaltenebene, weil personenbezogene Daten (PII) im Warehouse vorhanden sind, bevor Transformationen sie anonymisieren. Das bedeutet: Zugriffskontrollen müssen bereits auf der Rohschicht greifen. Nicht jeder Analyst darf auf jede Tabelle zugreifen.
Konkret brauchen ELT-Architekturen folgende Maßnahmen. Spaltenmaskierung für PII-Felder direkt in der Staging-Schicht. Rollenbasierte Zugriffskontrollen, die verhindern, dass Rohdaten breiter verfügbar sind als nötig. Audit-Logs auf Warehouse-Ebene, die nachvollziehbar machen, wer wann auf welche Daten zugegriffen hat.
Für Schweizer Unternehmen, die unter DSGVO oder dem revidierten Datenschutzgesetz (revDSG) arbeiten, ist dieser Punkt nicht optional. Die Governance-Architektur muss vor der ersten Datenpipeline stehen, nicht danach.
6. Entscheidungskriterien für IT-Manager
Die Wahl zwischen ELT und ETL ist eher strategisch als technikgetrieben und umfasst Governance, Kostenkontrolle und Infrastrukturüberlegungen. Folgende Kriterien helfen bei der Entscheidung.
1. Infrastruktur: Betreiben Sie ein Cloud-Warehouse mit elastischer Rechenleistung? Dann ist ELT der natürliche Ausgangspunkt. Arbeiten Sie mit On-Premise-Systemen oder Legacy-Datenbanken, ist ETL oft die einzige Option.
2. Datenvolumen und Geschwindigkeit: Große, dynamische Datenmengen mit häufig wechselnden Anforderungen sprechen für ELT. Kleine, stabile Datenmengen mit fester Transformationslogik funktionieren gut mit ETL.
3. Compliance-Anforderungen: Müssen Rohdaten das Warehouse nie erreichen? ETL. Können Sie Governance auf Warehouse-Ebene implementieren? ELT mit entsprechenden Sicherheitsmaßnahmen.
4. Teamkompetenzen: SQL-starke Analytics-Teams profitieren direkt von ELT und Tools wie dbt. Teams mit starker ETL-Expertise und bestehenden Pipelines sollten Migration nicht um ihrer selbst willen betreiben.
5. Kostenstruktur: ELT verlagert Kosten von fixer Transformationsinfrastruktur zu variablen Warehouse-Compute-Kosten. Das kann günstiger sein, muss es aber nicht. Analysieren Sie Ihre tatsächlichen Lastprofile.
6. Realtime-Anforderungen: Für Realtime ETL oder Near-Realtime-Szenarien, bei denen Daten innerhalb von Sekunden verfügbar sein müssen, brauchen Sie eine Streaming-Architektur (z. B. Apache Kafka). Weder klassisches ETL noch Batch-ELT löst dieses Problem allein.
7. Migrationsstrategie: Ein Wechsel von ETL zu ELT muss nicht vollständig sein. Viele Unternehmen migrieren schrittweise, beginnend mit neuen Datenquellen in ELT, während bestehende ETL-Pipelines weiterlaufen.
Profi-Tipp: Starten Sie mit einem Proof of Concept auf einer einzelnen Datenquelle, bevor Sie die gesamte Architektur umstellen. Das zeigt reale Kosten, Performance und Governance-Anforderungen, bevor Sie sich festlegen.
Wichtige Erkenntnisse
ELT ist für Cloud-Warehouse-Umgebungen der überlegene Ansatz, aber ETL bleibt bei Compliance-Anforderungen und Legacy-Infrastruktur unverzichtbar.
| Thema | Details |
|---|---|
| Kernunterschied ELT vs. ETL | ELT transformiert Daten im Warehouse, ETL in externer Middleware vor dem Laden. |
| ELT-Vorteil | Schnellerer Rohdatenzugriff und iterative Modellentwicklung ohne erneute Extraktion. |
| ETL-Vorteil | Bessere Kontrolle bei DSGVO-Compliance und On-Premise-Infrastruktur ohne Cloud-Warehouse. |
| Hybridansatz EtLT | Leichte Bereinigung vor dem Laden kombiniert mit komplexen SQL-Transformationen im Warehouse. |
| Entscheidungsgrundlage | Infrastruktur, Compliance, Teamkompetenz und Kostenstruktur bestimmen den richtigen Ansatz. |
Was Outwork nach Jahren in Datenprojekten gelernt hat
ELT gewinnt in der Praxis fast immer, wenn ein Cloud-Warehouse vorhanden ist. Das ist kein Hype. Es ist die logische Konsequenz davon, dass Warehouses wie Snowflake oder BigQuery für genau diese Arbeit gebaut wurden.
Aber es gibt einen Fehler, den wir immer wieder sehen: Teams implementieren ELT, ohne Governance von Anfang an mitzudenken. Rohdaten landen ungefiltert im Warehouse, Zugriffskontrollen fehlen, und nach sechs Monaten hat niemand mehr den Überblick, welche Tabellen produktiv genutzt werden. Das ist kein ELT-Problem. Es ist ein Architekturproblem.
Viele Pipelines, die als ELT bezeichnet werden, sind eigentlich ineffizientes ETL, weil die Transformationen nicht im Warehouse laufen. Das klingt nach einem technischen Detail, hat aber direkte Auswirkungen auf Performance und Kosten. Wer ELT richtig implementiert, nutzt die Warehouse-Engine als primäre Rechenressource.
Unsere Empfehlung für Schweizer Unternehmen: Beginnen Sie mit einer klaren Schichtenarchitektur (Staging, Intermediate, Mart) und definieren Sie Zugriffsrechte, bevor die erste Pipeline läuft. EtLT ist dabei oft der pragmatischste Einstieg, weil er die Stärken beider Ansätze verbindet, ohne die Governance-Anforderungen zu ignorieren.
— Outwork
Outwork begleitet Ihre Datenpipeline-Projekte
Datenpipelines sind kein reines Infrastrukturthema. Sie entscheiden darüber, wie schnell Ihr Unternehmen auf Daten zugreifen und Entscheidungen treffen kann.
Outwork entwickelt maßgeschneiderte Lösungen für Datenintegration und Softwareentwicklung, von der Architekturberatung über die Implementierung moderner ELT-Pipelines bis zur Integration in bestehende CRM- und ERP-Systeme. Mit über 1.200 aktiven Kunden kennen wir die spezifischen Anforderungen von Schweizer Unternehmen in regulierten Branchen. Ob Sie eine neue Cloud-Data-Architektur aufbauen oder bestehende ETL-Pipelines modernisieren wollen: Outwork bietet die technische Expertise und die passenden Leistungen für Ihr Vorhaben.
FAQ
Was ist der Hauptunterschied zwischen ELT und ETL?
Bei ETL werden Daten vor dem Laden in einer externen Middleware transformiert. Bei ELT landen Rohdaten zuerst im Warehouse, die Transformation folgt danach mit der Rechenleistung des Warehouses.
Wann sollte man ETL statt ELT verwenden?
ETL ist die bessere Wahl bei strikten Compliance-Anforderungen wie DSGVO-Pseudonymisierung vor dem Laden, bei On-Premise-Infrastruktur ohne Cloud-Warehouse und bei kleinen, stabilen Datenmengen mit fester Transformationslogik.
Was bedeutet EtLT?
EtLT kombiniert eine leichte Bereinigung vor dem Laden (kleines „t") mit komplexen SQL-Transformationen im Warehouse. Dieser hybride Ansatz eignet sich für Datenquellen mit Qualitätsproblemen, die eine Vorverarbeitung erfordern.
Wie funktioniert Realtime ETL?
Realtime ETL oder Near-Realtime-Verarbeitung erfordert eine Streaming-Architektur, zum Beispiel mit Apache Kafka. Klassisches Batch-ETL und Batch-ELT sind für Echtzeit-Szenarien nicht geeignet, weil sie Daten in Intervallen verarbeiten, nicht kontinuierlich.
Ist ELT immer günstiger als ETL?
Nicht zwingend. ELT verlagert Kosten von fixer Transformationsinfrastruktur zu variablen Warehouse-Compute-Kosten. Bei hohem Transformationsvolumen können Cloud-Warehouse-Kosten erheblich sein. Eine Analyse der tatsächlichen Lastprofile ist vor der Architekturentscheidung notwendig.
