SSIS vs. SQL — wann SSIS, wann reines T-SQL, wann beides kombinieren?

SSIS, T-SQL oder eine Kombination beider? Den einen richtigen Weg gibt es nicht. Was es gibt, ist eine Handvoll Entscheidungs-Kriterien, an denen jede konkrete Wahl — Technologie wie Einsatz-Umfang — gemessen werden sollte: Lesbarkeit, Quellcodeverwaltung, Identitätswechsel. Diese Artikel-Serie nimmt sich diese drei Achsen vor und liefert pro Achse ein konkretes Argument. Wer bei der ETL-Tool-Wahl ohne diese Kriterien argumentiert, landet in Tool-Loyalitäts-Debatten statt in Architektur-Entscheidungen.

Kurzüberblick:

SSIS vs. SQL ist eine Architektur-Frage, keine Tool-Loyalität.
Drei Vertiefungs-Achsen mit eigenen Cluster-Artikeln: Lesbarkeit/Wartbarkeit, Quellcodeverwaltung, Identitätswechsel.
Pragmatische Synthese: SSIS als Orchestrierungs-Wrapper, T-SQL-Substanz in Stored Procedures.
2026er-Einordnung: Microsoft Fabric Data Factory, dbt und Postgres-Bordmittel verschieben die Antwort, die Frage bleibt.

Voraussetzung: Grundkenntnisse in SQL Server 2017+ und SSIS 2017+ (Visual Studio mit SSDT).

Überblick

SQL Server Integration Services (SSIS) ist ein mächtiges Tool für die Entwicklung von ETL-Strecken. Es gibt viele gute Gründe für seinen Einsatz — und ebenso viele für einen maßvollen Umgang. Beschränkt man sich auf den Microsoft-Produkt-Stack (Azure-Welt zunächst ausgeklammert), kommt als Alternative für komplexe ETL-Strecken im Wesentlichen Transact-SQL (T-SQL) in Frage.

Diskussionen über die richtige Technologie — SSIS und/oder T-SQL — und das Ausmaß ihrer Verwendung enden häufig in philosophischen Auseinandersetzungen unter Entwicklern. Dabei gibt es nicht die eine richtige Antwort. Die optimale Lösung wird je nach Anforderungen regelmäßig eine Mischung aus beiden — oder sogar weiteren — Technologien sein. Diese Artikel-Serie beleuchtet die wichtigen Entscheidungs-Kriterien.

Häufig wird bei der Wahl auf Performance und Benchmark-Tests verwiesen. Performance spielt hier nur am Rande eine Rolle, weil sie bei den meisten realen Schnittstellen-Volumina ohnehin nicht der Engpass ist.

Die Tool-Loyalitäts-Falle

Häufig wird die Wahl entlang von Tool-Sympathie geführt. Wer mit T-SQL groß geworden ist, sieht in SSIS eine überflüssige Grafik-Schicht um eigentlich-SQL. Wer mit SSIS arbeitet, schätzt den strukturierenden Effekt des grafischen Designers und empfindet T-SQL als unübersichtliche Textmenge. Hinzu kommt ein Design-Aspekt, der die Sympathie-Linie zusätzlich verstärkt: Grafische ETL-Tools wie SSIS zielen bewusst auch auf Anwender mit weniger SQL-Erfahrung — der Designer senkt die Einstiegshürde und macht ETL-Strecken für BI-Praktiker zugänglich, die keinen tiefen T-SQL-Hintergrund mitbringen. Alle diese Argumente sind nachvollziehbar — als Architektur-Argument tragen sie aber nicht, weil sie am Tool hängen, nicht an den Anforderungen.

Die Frage ist nicht, welches Tool grundsätzlich besser ist, sondern welche Architektur-Eigenschaft im konkreten Fall trägt: Lesbarkeit eines Diffs, Berechtigungs-Kontext eines Job-Steps, Konnektor-Vielfalt für Datei-Integration, Versionierbarkeit eines Artefakts. Wer auf dieser Ebene argumentiert, kommt zu reproduzierbaren Entscheidungen — wer mit Tool-Loyalität argumentiert, zu vielen kleinen.

Was T-SQL gut kann

T-SQL gewinnt überall dort, wo Lesbarkeit, Versionierbarkeit und Set-basierte Performance zählen:

Set-basierte Mengen-Operationen — JOIN, aggregate Window-Functions, rekursive CTEs — sind in T-SQL kompakter und schneller als in SSIS-Pipelines mit Data-Flow-Buffern.
Versionierbarkeit — eine Stored Procedure ist Plain-Text-SQL und produziert einen zeilen-lesbaren Diff. Ein .dtsx-Paket erzeugt bei minimalen Änderungen ein GUID-Reordering-Erdbeben im XML — siehe Quellcodeverwaltung.
Lesbarkeit im Code-Review — Pull-Request-Diffs auf Plain-SQL sind einem Reviewer in 30 Sekunden zugänglich, der grafische Data-Flow-Designer nicht. Siehe Lesbarkeit/Wartbarkeit für die ausgebaute Argumentation an einem Hierarchie-Ranking-Beispiel.
Mathematische und analytische Transformationen — Window-Functions, GROUPING SETS, MERGE — sind in T-SQL First-Class. In SSIS müsste man Skript-Tasks oder mehrere Data-Flow-Komponenten verketten.

Was SSIS gut kann

SSIS gewinnt dort, wo der ETL-Job über die Datenbank-Grenze hinausgreift:

File-System-Integration — FTP, CSV, Excel, XML-Dateien, Verzeichnis-Traversierung, Datei-Bewegungs-Tasks. T-SQL kann hier prinzipiell mit BULK INSERT und OPENROWSET, aber SSIS ist mit den Standard-Konnektoren deutlich pragmatischer.
Konnektor-Vielfalt — Oracle, DB2, ODBC, OLE-DB, SAP, Salesforce: SSIS bringt die Out-of-the-Box-Treiber mit, die in einer reinen T-SQL-Welt manuell als Linked Server oder External Tables aufgesetzt werden müssten.
Pipeline-Buffer-Strategie und Parallelisierung — der Data-Flow-Task arbeitet mit Buffer-Pipelining: eine Zeile wird gelesen, transformiert und geschrieben, während die nächste schon im Lese-Buffer liegt. Bei langen Transformations-Ketten kann das Memory-Footprint und Durchsatz dominieren.
Job-Scheduling über SQL Server Agent + Impersonation — Agent-Jobs können SSIS-Pakete unter einem Proxy-User mit dediziertem Credential ausführen. T-SQL-Script-Steps haben das Run As nicht, weshalb für File-Share-Zugriff oder Cross-Instance-Auth der SSIS-Wrapper oft der einzige saubere Pfad ist — siehe Ident itätswechsel.
Operator-Tooling und Logging-Infrastruktur — SSIS Catalog (SSISDB) bringt strukturierte Ausführungs-Logs, Parameter-Override und Reporting mit, ohne eigene Logging-Tabellen zu pflegen.

Wann was kombinieren

Die pragmatische Synthese kommt selten als reine T-SQL– oder reine SSIS-Lösung — sondern als kombiniertes Pattern:

SSIS als Orchestrierungs-Wrapper: SSIS-Pakete liefern Datei-Integration, Konnektor-Mapping und Agent-Scheduling. Die eigentliche Transformations-Substanz liegt aber in Stored Procedures, die der Data-Flow oder ein Execute-SQL-Task aufruft. So bleiben die SQL-Diffs lesbar, das Versionskontroll-Argument trägt, und die SSIS-Vorteile (File-Konnektoren, Run-As, Catalog-Logging) bleiben erhalten. Siehe Lesbarkeit/Wartbarkeit für drei konkrete Lösungs-Varianten an einem Beispiel.
Heuristik: Wenn der Schritt CSV-Import + Datentransformation + INSERT ist → SSIS-Wrapper mit SP-Aufrufen. Wenn der Schritt rein SQL-Mengen-Operationen sind → pure Stored Procedure, vom Agent direkt als T-SQL-Script-Step aufgerufen (oder im Wrapper, falls Run-As-Pflicht besteht).
Anti-Pattern: Komplexe SQL-Logik in einer OLE-DB-Source-Komponente eines Data-Flows verstecken — der Code ist nicht versionierbar, nicht reviewbar, schwer testbar. Diese Substanz gehört in eine Stored Procedure.

Drei Entscheidungs-Kriterien im Cluster

Die drei Achsen, an denen jede konkrete Tool- und Vorgehensweise-Wahl gemessen werden sollte, sind als eigene Cluster-Artikel ausgebaut. Auch wenn der Cluster mit SSIS und T-SQL als Beispiel-Stack argumentiert, gelten die drei Kriterien Tool-übergreifend — wer mit Talend Open Studio, Pentaho / Kettle, Informatica oder Qlik Data Integration arbeitet, steht vor denselben Fragen: Lesbarkeit eines Diffs, Versionierbarkeit eines Artefakts, Berechtigungs-Kontext eines Job-Steps. Die Artefakt-Namen ändern sich, die Wartbarkeits- und Security-Eigenschaften nicht.

Lesbarkeit/Wartbarkeit — wie viel SQL gehört in ein SSIS-Paket? Drei Lösungs-Ansätze für dasselbe ETL-Beispiel, bewertet entlang von fünf Dimensionen (Entwicklungs-Dauer, Lesbarkeit, Wartbarkeit, Performance, Funktionsumfang).
Quellcodeverwaltung — warum SP-Diffs lesbar sind und .dtsx-Diffs nicht. Die Wartbarkeits-Entscheidung jenseits der Tool-Wahl: Welches Artefakt-Format trägt Versionskontrolle, welches nicht?
Identitätswechsel — Proxy-User, Credential, das Run As-Property pro Step-Typ. Pflicht-Lektüre, sobald Agent-Jobs auf File Shares oder Cross-Instance-Ressourcen zugreifen müssen — und der Grund, warum SSIS-Pakete als Wrapper für ansonsten reine SP-Pipelines unverzichtbar werden.

ETL 2026

Die ursprüngliche Frage „SSIS und/oder T-SQL?“ wurde 2018 im Rahmen des On-Prem-Microsoft-Stacks gestellt. Acht Jahre später hat sich die Tool-Landschaft erweitert — die Frage bleibt relevant, die Antwort verschiebt sich.

Microsoft-Stack heute

SSIS bleibt supported (SQL Server 2022 inklusive), und über die Azure-SSIS-Integration-Runtime lassen sich vorhandene Pakete in Azure Data Factory (ADF) ausführen — der Lift-and-Shift-Pfad ist intakt. Für neue ETL-Projekte im Microsoft-Cloud-Stack ist aber nicht mehr SSIS der Default, sondern ADF selbst (mit Mapping-/Wrangling-Data-Flows) bzw. Synapse Pipelines im Synapse-Analytics-Umfeld. Seit 2024 konsolidiert Microsoft die Cloud-ETL-Welt unter Microsoft Fabric Data Factory und positioniert es explizit als „next generation of Azure Data Factory“ — inklusive PowerShell-Migrations-Tool für den Wechsel von ADF nach Fabric. Synapse Pipelines wandert perspektivisch ebenfalls in Fabric. Standalone-ADF bleibt für bestehende Pipelines und Lift-and-Shift-Szenarien (insbesondere die Azure-SSIS-Integration-Runtime, die in Fabric Data Factory kein direktes Pendant hat) erhalten — neue Projekte werden zunehmend in Fabric aufgesetzt. Das Diff-Problem (JSON-Pipeline-Definitionen statt XML-.dtsx) verlagert sich, ohne grundsätzlich gelöst zu sein.

Postgres- und SQL-zentrische Welt

Außerhalb des Microsoft-Stacks haben sich drei Tool-Klassen etabliert, die SSIS-Funktionalität neu schneiden:

Postgres-Bordmittel (LATERAL, Foreign Data Wrappers, COPY) ersetzen viele Konnektor- und Datei-Integrations-Szenarien, für die früher SSIS nötig war.
dbt ist der Standard für Transform-Layer-Versionierung — alles SQL-as-Code, mit Git-Diff-Lesbarkeit, Tests und Lineage. Genau das, was .dtsx-Pakete strukturell nicht liefern können.
Airflow, Prefect oder Dagster orchestrieren die Pipeline (das, was sonst der SQL Server Agent gemacht hat), in der Regel Container-basiert und mit erstklassiger Code-Versionierung.

Wer einen Postgres-, BigQuery- oder Snowflake-Stack betreibt, kommt selten an SSIS vorbei — die ETL-2026-Welt wählt aus dbt + Orchestrator + nativen Datenbank-Konstrukten.

Die Frage bleibt: was lässt sich wartungsfreundlich abbilden?

Was die drei Achsen aus dem Cluster (Lesbarkeit, Quellcodeverwaltung, Identitätswechsel) ausmacht, ist nicht SSIS-spezifisch. Es ist die generelle Frage, welches Artefakt-Format Versionskontrolle, Code-Review und granulare Security-Kontexte trägt — und welches nicht. SSIS liegt auf der schwierigen Seite (XML, GUID-Reordering, kompakte Wrapper-Funktion für Auth). ADF und Synapse Pipelines liegen mit ihren JSON-Definitionen besser, aber nicht in der dbt-/SP-Liga. Plain-SQL — egal ob in einer Stored Procedure oder einem dbt-Model — bleibt das Format mit der höchsten Wartbarkeit pro Entwicklerstunde.

Take-Away

Die Frage „SSIS oder T-SQL?“ ist eine Architektur-Entscheidung, keine Tool-Loyalitäts-Frage.
T-SQL gewinnt bei Lesbarkeit, Versionierbarkeit und Set-basierter Performance; SSIS gewinnt bei File-Integration, Konnektor-Vielfalt und Job-Scheduling mit Impersonation.
Die pragmatische Synthese: SSIS als Orchestrierungs-Wrapper, SQL-Substanz in Stored Procedures.
2026 bleibt die Frage relevant, aber die Antwort verschiebt sich Richtung Cloud (Microsoft Fabric Data Factory als offizieller ADF-Nachfolger, Synapse Pipelines wandert mit) und versionierbare Transform-Tools (dbt, Postgres-Bordmittel).

FAQ

Soll ich neue ETL-Projekte 2026 noch mit SSIS starten?

Im klassischen On-Prem-SQL-Server-Stack ja, wenn Datei-Integration und Agent-Job-Scheduling im Vordergrund stehen — SSIS ist dort weiter das pragmatische Tool. In einem Cloud- oder Postgres-Stack eher nicht: Azure Data Factory / Microsoft Fabric Data Factory bzw. dbt + Airflow decken die gleichen Aufgaben mit besserer Versionskontroll- und Diff-Pragmatik ab.

Was ist der pragmatische Mittelweg zwischen pure T-SQL und pure SSIS?

SSIS als Orchestrierungs-Wrapper, der Datei-Integration, Konnektor-Mapping und Agent-Scheduling übernimmt — die eigentliche Transformations-Substanz lebt in Stored Procedures, die das SSIS-Paket aufruft. So bleiben die SQL-Diffs lesbar, die Versionskontrolle trägt, und SSIS-Vorteile (Run-As, SSISDB-Catalog-Logging, Konnektor-Bibliothek) bleiben erhalten. Siehe Lesbarkeit/Wartbarkeit für drei konkrete Lösungs-Varianten an einem Beispiel.

Wo liegt der wirkliche Mehrwert von SSIS gegenüber reinem T-SQL?

Drei Bereiche: erstens File-System-Integration und Konnektor-Vielfalt (FTP, CSV, Excel, Oracle, SAP — alles out-of-the-box). Zweitens Pipeline-Buffer-Strategie mit überlappendem Lesen/Transformieren/Schreiben, die bei langen Transformations-Ketten den Durchsatz dominiert. Drittens Run-As-Pflicht für Agent-Jobs, die auf File Shares oder Cross-Instance-Ressourcen zugreifen müssen — T-SQL-Script-Steps unterstützen kein Run As, SSIS-Pakete schon (siehe Identitätswechsel).

Welche modernen Tools ersetzen SSIS in Cloud-/Postgres-Stacks?

Im Microsoft-Cloud-Stack: Azure Data Factory und Microsoft Fabric Data Factory (Fabric konsolidiert seit 2024 ADF und Synapse Pipelines). Im offenen Stack: dbt für Transform-Layer-Versionierung (SQL-as-Code mit Git-Diffs und Tests), Airflow / Prefect / Dagster für Orchestrierung, Postgres-Bordmittel (LATERAL, FDW, COPY) für viele Konnektor-Szenarien.

Ist Microsoft Fabric Data Factory der direkte SSIS-Nachfolger?

Nicht direkt. Fabric Data Factory ist offiziell der Nachfolger von Azure Data Factory — Microsoft Learn formuliert es als „next generation of Azure Data Factory“. SSIS-Pakete laufen weiterhin über die Azure-SSIS-Integration-Runtime in ADF — Fabric Data Factory hat dafür kein direktes Pendant. Funktional decken Fabric-Pipelines die typischen SSIS-Aufgaben (Datei-Import, Pipeline-Orchestrierung, Konnektor-Mapping) ab, mit JSON-basierten Pipeline-Definitionen statt XML-.dtsx. Wer von SSIS weg will, hat zwei Pfade: Lift-and-Shift in die Azure-SSIS-IR (kurzfristig) oder neu-aufsetzen in Fabric Data Factory bzw. ADF-nativen Pipelines (langfristig).

Gelten diese Entscheidungs-Kriterien auch für andere ETL-Tools wie Talend, Pentaho oder Informatica?

Ja. Der Cluster argumentiert mit SSIS und T-SQL als Beispiel-Stack, aber die drei Achsen — Lesbarkeit, Quellcodeverwaltung, Identitätswechsel — sind generische ETL-Tool-Fragen. Talend Open Studio, Pentaho / Kettle, Informatica und Qlik Data Integration unterscheiden sich in den konkreten Artefakt-Formaten (XML, JSON, proprietäre Container) und in den Sicherheits-Modellen (Service-Accounts, Run-As-Pendants, Credential-Stores), aber die strukturellen Wartbarkeits-Fragen sind dieselben. Wer von einem dieser Stacks kommt, kann die Cluster-Argumentation 1:1 auf seine Tool-Welt übertragen — nur die Artefakt-Namen und API-Aufrufe ändern sich. Die Synthese „Orchestrierungs-Wrapper-Tool plus SQL-Substanz in Stored Procedures“ funktioniert analog mit Talend-/Pentaho-Jobs als Wrapper.