SSIS vs. T-SQL: wann welches Werkzeug? 3 Kriterien

Eine CSV-Datei einlesen, die Daten transformieren, das Ergebnis in SQL Server laden: Für den Datei-Teil liegt SSIS nahe, für die Transformation reines T-SQL. Die beste Lösung ist oft die Kombination aus beiden. Den einen richtigen Weg gibt es nicht, wohl aber drei Entscheidungs-Kriterien, an denen sich jede konkrete Wahl messen lassen sollte: Lesbarkeit, Quellcodeverwaltung, Identitätswechsel. Diese Artikel-Serie nimmt sich die drei Achsen vor und liefert pro Achse ein konkretes Argument.

Kurzüberblick:

SSIS vs. SQL ist eine Architektur-Frage, keine Tool-Loyalität.
Drei Vertiefungs-Achsen mit eigenen Artikeln: Lesbarkeit/Wartbarkeit, Quellcodeverwaltung, Identitätswechsel.
Pragmatische Synthese für SQL-zentrierte Strecken: SSIS als Orchestrierungs-Wrapper, die Transformations-Logik 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 und klammert die Azure-Welt zunächst aus, 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 über das Ausmaß ihrer Verwendung enden häufig in philosophischen Auseinandersetzungen unter Entwicklern. Dabei gibt es nicht die eine richtige Antwort. Welche Mischung optimal ist, hängt von den Anforderungen ab, manchmal kommen sogar weitere Technologien dazu. Diese Artikel-Serie beleuchtet die wichtigen Entscheidungs-Kriterien.

Häufig wird bei der Wahl auf Performance und Benchmark-Tests verwiesen. Laufzeit und Durchsatz spielen hier aber nur am Rande eine Rolle, weil sie bei den meisten realen Schnittstellen-Volumina nicht der Engpass sind. Mehr dazu steht in der FAQ.

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 das eigentliche 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 trotzdem nicht, weil sie am Tool hängen und 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, führt dieselbe Debatte beim nächsten Projekt von vorn.

Was T-SQL gut kann

T-SQL gewinnt dort, wo Lesbarkeit, Versionierbarkeit und set-basierte Ausdrucksstärke zählen:

Set-basierte Mengen-Operationen: JOINs, Aggregat- und Window-Functions sowie rekursive CTEs lassen sich in T-SQL kompakter und näher am Datenmodell ausdrücken als in einer Kette von SSIS-Data-Flow-Komponenten. Ob die T-SQL-Variante auch schneller läuft, hängt vom Szenario ab (siehe FAQ).
Versionierbarkeit: Eine Stored Procedure ist Plain-Text-SQL und produziert einen zeilen-lesbaren Diff. Ein .dtsx-Paket kann dagegen schon bei minimalen Änderungen ein GUID-Reordering-Erdbeben im XML auslösen. Warum das so ist, zeigt der Artikel 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. Der Artikel Lesbarkeit/Wartbarkeit baut diese Argumentation an einem Hierarchie-Ranking-Beispiel aus.
Mathematische und analytische Transformationen: Window-Functions und GROUPING SETS sind native T-SQL-Sprachmittel. Auch MERGE steht bereit, verlangt wegen seiner dokumentierten Einschränkungen aber einen prüfenden Blick. In SSIS müsste man für solche Logik 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 und Datei-Bewegungs-Tasks deckt SSIS mit nativen Tasks und Komponenten ab. T-SQL kann Dateien mit BULK INSERT und OPENROWSET einlesen und anschließend in der Engine verarbeiten. Für die Datei-Orchestrierung drumherum, etwa Dateisuche, Verschieben oder FTP, bietet SSIS deutlich mehr fertige Bausteine.
Konnektor-Vielfalt: SSIS bringt eine breite Auswahl an Konnektoren für relationale Datenbanken, Dateien und Unternehmens-Systeme mit. Für Systeme wie Oracle, DB2 oder SAP sind je nach Szenario zusätzliche Provider, Treiber oder lizenzpflichtige Komponenten nötig. In einer reinen T-SQL-Welt müsste derselbe Zugriff manuell als Linked Server oder External Table aufgesetzt werden.
Buffering und Pipeline-Parallelität: Der Data-Flow-Task verarbeitet Daten in Buffern, die jeweils viele Zeilen fassen. Während eine Komponente einen Buffer transformiert, können andere Komponenten parallel an weiteren Buffern arbeiten. Buffer-Größe, Transformations-Typen und die Eigenschaften von Quelle und Ziel bestimmen Speicherbedarf und Durchsatz.
Job-Scheduling über SQL Server Agent mit Impersonation: Ein SSIS-Job-Step kann unter einem Agent-Proxy laufen, der auf einem Credential basiert, für das SSIS-Subsystem freigegeben ist und einen dedizierten Windows-Sicherheitskontext bereitstellt. T-SQL-Job-Steps verwenden dagegen keine Agent-Proxies. Ihr Datenbank-Kontext ergibt sich per EXECUTE AS aus dem Job-Besitzer, einen alternativen Windows-Kontext erhalten sie nicht. Sobald ein Job auf File Shares oder andere Instanzen zugreifen muss, braucht es deshalb ein Proxy-fähiges Subsystem — neben SSIS können das auch CmdExec- oder PowerShell-Steps sein. SSIS ist die naheliegende Wahl, wenn der Job ohnehin ein Paket ausführt, siehe Identitätswechsel.
Operator-Tooling und Logging-Infrastruktur: Der SSIS-Katalog (SSISDB) bringt technische Ausführungs-Logs, Parameter-Override und Reporting mit, ohne dass eigene Logging-Tabellen zu pflegen wären. Fachliche ETL-Logs, etwa die Zahl verarbeiteter oder verworfener Datensätze, brauchen trotzdem ein eigenes Konzept — eine SQL-Lösung dafür zeigt Design Pattern // Protokollierung eines ETL-Prozesses mit SQL.

Wann was kombinieren

Die beiden Stärken-Profile im direkten Vergleich:

Kriterium	T-SQL	SSIS
Set-basierte Transformation innerhalb der Engine	sehr stark	meist unnötige Zwischenschicht
Datei-Import	`BULK INSERT`, `OPENROWSET`	native Tasks und Komponenten
Datei-Orchestrierung (FTP, Verschieben, Schleifen)	kaum Bordmittel	stark
Konnektoren zu Fremdsystemen	Linked Server, External Tables (manuell)	breite Konnektor-Auswahl
Git-Diff und Code-Review	zeilen-lesbar	XML-Diff schwer lesbar
Agent-Proxy (eigener Windows-Kontext)	nein	ja

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-Logik 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 wie File-Konnektoren, Proxy-Ausführung und Catalog-Logging bleiben erhalten. Dieses Pattern eignet sich vor allem für SQL-zentrierte Strecken, deren Daten ohnehin in die Engine fließen. Wo Daten bewusst im Data-Flow transformiert werden, etwa beim Streaming zwischen externen Systemen, bleibt das eine legitime Design-Entscheidung. Drei konkrete Lösungs-Varianten an einem Beispiel zeigt der Artikel Lesbarkeit/Wartbarkeit.
Heuristik: Besteht ein Schritt aus CSV-Import, Datentransformation und INSERT, passt der SSIS-Wrapper mit SP-Aufrufen. Besteht er rein aus SQL-Mengen-Operationen, reicht eine Stored Procedure, die der SQL Server Agent direkt als T-SQL-Script-Step aufruft. Braucht der Job einen Proxy-Sicherheitskontext, läuft auch er im SSIS-Wrapper.
Anti-Pattern: Komplexe SQL-Logik in einer OLE-DB-Source-Komponente eines Data-Flows zu verstecken. Der SQL-Code liegt dann als Paket-Property im .dtsx und ist damit zwar technisch versioniert, aber kaum diff- und reviewbar und schwer isoliert zu testen. Diese Logik 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, werden in eigenen Artikeln vertieft. Auch wenn diese Serie 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 und die Run as-Einstellung des jeweiligen Step-Typs. 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 oft die passende Lösung sind.

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 eingeschlossen. Über die Azure-SSIS-Integration-Runtime lassen sich vorhandene Pakete in Azure Data Factory (ADF) ausführen, der Lift-and-Shift-Pfad ist also intakt. Für neue ETL-Projekte im Microsoft-Cloud-Stack ist aber nicht mehr SSIS der Default, sondern ADF selbst mit seinen Mapping- und Wrangling-Data-Flows, im Synapse-Analytics-Umfeld auch Synapse Pipelines. Seit 2024 führt Microsoft die Cloud-ETL-Welt unter Microsoft Fabric Data Factory zusammen und positioniert es explizit als „next generation of Azure Data Factory“. Für den Wechsel von ADF nach Fabric stellt Microsoft ein PowerShell-Migrations-Tool bereit. Auch für Synapse Pipelines stellt Microsoft Migrations-Pfade nach Fabric bereit. ADF bleibt daneben relevant, insbesondere für bestehende Pipelines und für die Azure-SSIS-Integration-Runtime, die in Fabric Data Factory bislang kein direktes Pendant hat (Stand: September 2026). Das Diff-Problem verlagert sich damit von XML-.dtsx auf JSON-Pipeline-Definitionen, 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: COPY deckt effiziente Datei-Importe und -Exporte ab, Foreign Data Wrappers binden externe Datenquellen direkt ein. Zusammen decken sie viele Import- und Anbindungs-Szenarien ab, die im SQL-Server-Stack häufig mit SSIS gelöst würden. Die übergreifende Orchestrierung bleibt eigenen Werkzeugen überlassen. SQL-Konstrukte wie LATERAL erweitern dagegen die Ausdrucks-Möglichkeiten innerhalb der Transformation.
dbt hat sich für die Versionierung des Transform-Layers breit etabliert: alles SQL-as-Code, mit Git-Diff-Lesbarkeit, Tests und Lineage. Genau das können .dtsx-Pakete strukturell nicht liefern.
Airflow, Prefect oder Dagster orchestrieren die Pipeline und übernehmen damit die Aufgabe, die im klassischen Stack der SQL Server Agent hatte. Ihre Pipeline-Definitionen sind Code und damit erstklassig versionierbar. Das Deployment reicht von Containern über Kubernetes bis zu klassischen Worker-Umgebungen.

Wer einen Postgres-, BigQuery- oder Snowflake-Stack betreibt, kommt mit SSIS nur noch selten in Berührung. Die ETL-Welt des Jahres 2026 wählt dort meist aus dbt, Orchestrator und nativen Datenbank-Konstrukten.

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

Was die drei Achsen Lesbarkeit, Quellcodeverwaltung und 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-Artefakte, GUID-Reordering im Diff, und beim Berechtigungs-Kontext punktet es vor allem als kompakter Wrapper. ADF- und Synapse-Pipelines sind als JSON-Artefakte textbasiert versionierbar. Für SQL-zentrierte Transformationen bleibt Plain-SQL trotzdem das Artefakt, das sich am leichtesten diffen, reviewen und testen lässt — egal ob als Stored Procedure oder dbt-Model. Die tragfähigere Frage lautet damit nicht „SSIS oder T-SQL?“, sondern: Welche Teile der Pipeline brauchen eine Integrations-Plattform, und welche gehören als SQL-Logik in die Datenbank?

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 Ausdrucksstärke. SSIS gewinnt bei File-Integration, Konnektor-Vielfalt und Job-Scheduling mit Proxy-Impersonation.
Die pragmatische Synthese für SQL-zentrierte Strecken: SSIS als Orchestrierungs-Wrapper, die Transformations-Logik in Stored Procedures.
2026 bleibt die Frage relevant, aber die Antwort verschiebt sich: in der Microsoft-Cloud zu Fabric Data Factory als nächster Data-Factory-Generation, im offenen Stack zu versionierbaren Transform-Tools wie dbt und zu Postgres-Bordmitteln.

Für die Praxis als Entscheidungshilfe:

Eingangslage	Empfohlener Weg
SQL-zu-SQL-Transformation innerhalb einer Instanz	Stored Procedure, vom Agent direkt als T-SQL-Step aufgerufen
Dateiimport plus SQL-Transformation	SSIS-Wrapper außen, Stored Procedures innen
Viele heterogene Quellsysteme	SSIS (On-Prem) bzw. ADF/Fabric (Cloud) als Konnektor-Schicht
Agent-Job braucht File-Share- oder Cross-Instance-Zugriff	Step-Typ mit Agent-Proxy, typischerweise SSIS
Cloud-natives Neuprojekt im Microsoft-Stack	Fabric Data Factory, Transformation in SQL
Postgres-, BigQuery- oder Snowflake-Stack	dbt plus Orchestrator, native Datenbank-Konstrukte

FAQ

Was ist der Unterschied zwischen SSIS und T-SQL?

SSIS (SQL Server Integration Services) ist eine grafische Integrations-Plattform: Pakete mit Data-Flows, Tasks und Konnektoren, entwickelt in Visual Studio, ausgeführt als eigene Laufzeit. T-SQL ist der SQL-Dialekt von SQL Server und läuft direkt in der Datenbank-Engine, typischerweise als Stored Procedures. SSIS bewegt und orchestriert Daten über System-Grenzen hinweg, T-SQL transformiert Mengen innerhalb der Engine.

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 weiterhin das pragmatische Tool. In einem Cloud- oder Postgres-Stack eher nicht: Azure Data Factory beziehungsweise Microsoft Fabric Data Factory und dbt plus Airflow decken dieselben Aufgaben mit besserer Versionskontroll- und Diff-Pragmatik ab.

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

SSIS dient als Orchestrierungs-Wrapper und übernimmt Datei-Integration, Konnektor-Mapping und Agent-Scheduling. Die eigentliche Transformations-Logik lebt in Stored Procedures, die das SSIS-Paket aufruft. So bleiben die SQL-Diffs lesbar, die Versionskontrolle trägt, und die SSIS-Vorteile Proxy-Ausführung, SSISDB-Catalog-Logging und Konnektor-Bibliothek bleiben erhalten. Drei konkrete Lösungs-Varianten an einem Beispiel zeigt der Artikel Lesbarkeit/Wartbarkeit.

Ist SSIS schneller als T-SQL?

Pauschal lässt sich das nicht beantworten. Liegen Quelle, Transformation und Ziel in derselben Engine, vermeidet T-SQL unnötige Datenbewegung und ist deshalb häufig attraktiv. Der SSIS-Data-Flow kann punkten, wenn Quelle und Ziel getrennte Systeme sind und die Daten ohnehin gestreamt werden müssen. Wer die Entscheidung an der Laufzeit festmachen will, kommt um eine Messung im eigenen Szenario mit realistischen Datenmengen nicht herum.

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

In drei Bereichen. Erstens bei der File-System-Integration und Konnektor-Vielfalt: Datei-Orchestrierung, FTP und die Konnektor-Bibliothek funktionieren ohne Eigenbau. Zweitens beim Buffering mit Pipeline-Parallelität, das bei getrennten Quell- und Zielsystemen den Durchsatz trägt. Drittens bei Agent-Jobs, die einen Proxy-Sicherheitskontext brauchen: T-SQL-Job-Steps unterstützen keine Agent-Proxies, SSIS-Steps schon (siehe Identitätswechsel).

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

Im Microsoft-Cloud-Stack sind es Azure Data Factory und Microsoft Fabric Data Factory. Microsoft positioniert Fabric als nächste Generation von ADF, während ADF und Synapse Pipelines für vorhandene Azure-Workloads weiterbestehen. Im offenen Stack versioniert dbt den Transform-Layer als SQL-as-Code mit Git-Diffs und Tests, Airflow, Prefect oder Dagster übernehmen die Orchestrierung, und Postgres-Bordmittel wie COPY und Foreign Data Wrappers decken viele Import- und Anbindungs-Szenarien ab.

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, für die Fabric Data Factory bislang kein direktes Pendant hat (Stand: September 2026). Funktional decken Fabric-Pipelines die typischen SSIS-Aufgaben wie Datei-Import, Pipeline-Orchestrierung und Konnektor-Mapping ab, mit JSON-basierten Pipeline-Definitionen statt XML-.dtsx. Wer von SSIS weg will, hat zwei Pfade: kurzfristig den Lift-and-Shift in die Azure-SSIS-IR, langfristig das Neu-Aufsetzen in Fabric Data Factory oder ADF-nativen Pipelines.

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

Ja. Diese Artikel-Serie argumentiert mit SSIS und T-SQL als Beispiel-Stack, aber die drei Achsen Lesbarkeit, Quellcodeverwaltung und 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), die strukturellen Wartbarkeits-Fragen sind aber dieselben. Wer von einem dieser Stacks kommt, kann die Argumentation der Serie 1:1 auf seine Tool-Welt übertragen, nur die Artefakt-Namen und API-Aufrufe ändern sich. Die Synthese „Orchestrierungs-Wrapper-Tool plus Transformations-Logik in Stored Procedures“ funktioniert analog mit Talend- oder Pentaho-Jobs als Wrapper.