PolyBase mit erweiterten Konnektoren: Zugriff auf externe Datenquellen direkt aus SQL Server 2025

Warum ich PolyBase einsetze

Wenn Du Daten aus anderen Systemen holen willst – CSV, Oracle, S3, PostgreSQL, Hadoop oder sogar Azure Blob – dann ist PolyBase in SQL Server 2025 der direkteste Weg.
Ohne SSIS. Ohne Skripte. Ohne Dritttools.
Du schreibst einfach ein SELECT, als wäre es eine lokale Tabelle.

Was sich in 2025 verbessert hat

• Neue Konnektoren: MariaDB, IBM DB2, Snowflake
• Unterstützung für Azure AD auth bei Blob/Synapse
• Verbesserte Performance bei Pushdown-Queries
• Bessere Fehlermeldungen (endlich!)

Ich zeige Dir, wie ich PolyBase produktiv nutze – mit echten Anwendungsfällen in KMU-Projekten.

1. Grundvoraussetzungen

• SQL Server 2025 installiert (mit PolyBase aktiviert)
• Feature PolyBase Data Movement Service (DMS) aktiv
• sp_configure korrekt gesetzt

EXEC sp_configure 'polybase enabled', 1;
RECONFIGURE;

2. Zugriff auf CSV-Dateien im Netzwerk

Datenquelle einrichten

CREATE EXTERNAL DATA SOURCE MyCsvSource
WITH (
    LOCATION = 'file://\\server\freigabe\csv',
    FORMAT_OPTIONS (FIELD_TERMINATOR = ';', STRING_DELIMITER = '"'),
    CREDENTIAL = [CsvCred]
);

Format definieren

CREATE EXTERNAL FILE FORMAT CsvFormat
WITH (
    FORMAT_TYPE = DELIMITEDTEXT,
    FORMAT_OPTIONS (
        FIELD_TERMINATOR = ';',
        STRING_DELIMITER = '"',
        FIRST_ROW = 2
    )
);

Tabelle referenzieren

CREATE EXTERNAL TABLE ext_kunden (
    kundennr INT,
    name NVARCHAR(100),
    ort NVARCHAR(100)
)
WITH (
    LOCATION = 'kunden.csv',
    DATA_SOURCE = MyCsvSource,
    FILE_FORMAT = CsvFormat
);

Daten abfragen

SELECT * FROM ext_kunden WHERE ort = 'Hamburg';

Und das läuft wie eine normale Tabelle – mit WHERE, JOIN, TOP, alles.

3. Zugriff auf PostgreSQL (z. B. aus Webshops)

ODBC-Konfiguration

Installiere den PostgreSQL-ODBC-Treiber.
Dann in SQL:

CREATE EXTERNAL DATA SOURCE PostgresShop
WITH (
    LOCATION = 'odbc://PostgreSQL35W',
    CONNECTION_OPTIONS = 'Driver={PostgreSQL Unicode};Server=shop-db;Database=webshop;',
    CREDENTIAL = [pg_cred]
);

CREATE EXTERNAL TABLE ext_bestellungen (
    bestellnr INT,
    kunde TEXT,
    summe DECIMAL(10,2)
)
WITH (
    DATA_SOURCE = PostgresShop
);

Jetzt kannst Du direkt z. B. Bestellungen im Access-Frontend analysieren – per OPENQUERY oder direktem JOIN mit internen Artikeldaten.

4. Zugriff auf Azure Blob Storage

Credential anlegen

CREATE DATABASE SCOPED CREDENTIAL azure_blob_cred
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=2024-01...&se=2025-01...';

Datenquelle anlegen

CREATE EXTERNAL DATA SOURCE AzureBlobCSV
WITH (
    LOCATION = 'https://meinblob.blob.core.windows.net/reports',
    CREDENTIAL = azure_blob_cred
);

Dann wieder wie bei CSV eine EXTERNAL TABLE erstellen.

5. Zugriff auf andere SQL Server

Auch das ist nützlich, wenn mehrere Systeme im Haus laufen.

CREATE EXTERNAL DATA SOURCE SqlBackend
WITH (
    LOCATION = 'sqlserver://sql-backend.firma.lan',
    CREDENTIAL = [sql_cred]
);

Dann kannst Du direkt Tabellen aus anderen SQL Servern abfragen – ohne Linked Server, ohne SSIS.

6. JOIN über Systeme

SELECT a.artikelnummer, a.bezeichnung, b.summe
FROM artikel a
JOIN ext_bestellungen b ON a.artikelnummer = b.artikelnummer
WHERE b.summe > 100;

PolyBase schiebt die WHERE-Bedingung (Pushdown) soweit wie möglich zur Quelle.
Du bekommst bessere Performance als mit OpenQuery oder VBA-ODBC-Schleifen.

7. Limitierungen

Thema	Stand 2025
INSERT/UPDATE	Nur in SQL Server, nicht extern
FORMAT_JSON	Nur in Azure Synapse
Schema Drift	Muss manuell abfangen
JOIN-Tiefe	Je nach Quelle begrenzt

Wenn’s zu komplex wird, packe ich ein Staging-Table dazwischen.

Mein polygonales Fazit

PolyBase ist die Lösung, wenn Du Daten lesen willst.
Schnell. Wartbar. Direkt aus SQL.
In KMU reicht das oft völlig – und ersetzt viele ETL-Skripte.