SQL on Files: Definition, Funktionsweise und Abgrenzung

SQL on Files bezeichnet das Abfragen von Daten mit SQL (Structured Query Language, die Standard-Abfragesprache für Datenbanken) direkt auf einzelnen Dateien in einem Objekt-Speicher (günstiger Cloud-Ablageort für Dateien, zum Beispiel Amazon S3). Die Dateien bleiben, wo sie sind, meist in offenen Formaten wie Parquet (spaltenweises Datenformat) oder CSV. Sie werden nicht vorher in eine klassische Datenbank geladen. Aus diesem Muster wird ein Lakehouse (moderne Datenplattform, die Data-Warehouse-Funktionen auf einem Datei-Speicher bereitstellt), sobald ein sogenanntes Table Format wie Delta Lake oder Apache Iceberg über die Dateien gelegt wird.

Was ist SQL on Files?

SQL on Files ist ein Zugriffsmuster: Ein Abfrage-Werkzeug (die sogenannte SQL-Engine, etwa Spark SQL, Databricks SQL, Trino, DuckDB oder Amazon Athena) liest Dateien direkt aus dem Cloud-Speicher und interpretiert sie so, als wären sie eine Tabelle. Welche Spalten es gibt und welchen Datentyp sie haben, entnimmt die Engine entweder der Datei selbst (spaltenweise Formate wie Parquet oder ORC tragen diese Angaben intern mit) oder einem Katalog (zentrales Verzeichnis, das Datei-Pfaden einen Tabellennamen und ein Schema zuordnet, zum Beispiel Hive Metastore, AWS Glue oder Unity Catalog). Die Daten liegen dabei am ursprünglichen Ort im Cloud-Speicher (Amazon S3, Azure Data Lake Storage, Google Cloud Storage oder SAP HANA Data Lake Files); es entsteht keine zweite Kopie in einem eigenen, herstellerspezifischen Warehouse-Format.

Zwei Ausprägungen sind verbreitet. In der ad-hoc-Form liest die Engine einen Datei-Pfad direkt, ohne Katalog-Eintrag: SELECT * FROM parquet.\s3://bucket/pfad/\` in Databricks SQL, read_parquet('s3://bucket/pfad/') in DuckDB, SELECT * FROM hive.default."$path"` in Trino. In der kataloggeführten Form definiert ein Katalog eine External Table oder eine Managed Table über einem Files-Pfad; die SQL-Engine referenziert die Tabelle wie eine relationale Tabelle, liest aber weiter aus dem Objekt-Speicher.

Die Performance hängt am Format. Parquet und ORC liefern Row-Group- oder Stripe-Statistiken (Min/Max, Null-Count), auf denen die Engine Predicate Pushdown, Column Projection und Partition Pruning entlang der Verzeichnisstruktur (year=2026/month=07/) anwendet. Bei CSV und JSON greifen diese Optimierungen nur teilweise, weil das Format keine Statistiken enthält. SQL on Files auf JSON-Landing-Zonen ist deshalb häufig ein Zwischenschritt zur spaltenweisen Materialisierung nach Parquet.

Ein zentraler Punkt ist die fehlende Transaktions-Semantik. Reines SQL on Files kennt kein Commit-Log; parallele Schreib- und Leseoperationen auf denselben Dateien können inkonsistente Zwischenstände liefern, und Schema-Änderungen an den Quell-Dateien schlagen bei den Readern still auf. Historisch stammt das Muster aus der Hadoop-Ära (Hive-Queries gegen HDFS-Verzeichnisse) und ist mit der Reife offener Datei-Formate (Parquet 2013, ORC 2013), verteilter SQL-Engines (Spark SQL, Presto, Trino) und Objekt-Speicher als Standard-Cloud-Storage in die Public Cloud gewandert. Table Formats wie Delta Lake, Apache Iceberg und Apache Hudi setzen genau an dieser Lücke an: Sie legen ein Transaktions-Log oder eine Snapshot-Hierarchie neben die Datendateien und wandeln SQL on Files in eine transaktionale Tabelle.

Abgrenzung zu Data Warehouse, Lakehouse, External Tables und Federation

SQL on Files wird in Diskussionen häufig mit benachbarten Zugriffsmustern vermischt, weil dieselbe SQL-Engine je nach Konfiguration mehrere davon parallel unterstützt.

Begriff	Achse	Kernunterschied
Data Warehouse	Verwalteter proprietärer Storage	Ein Warehouse speichert Daten in einem eigenen, proprietären Format (Snowflake FDN, BigQuery Capacitor, Redshift RA3, klassisch Teradata- und Oracle-Blöcke) und verwaltet Statistiken, Indizes und Vacuum selbst. SQL on Files trennt Storage (offenes Format im Objekt-Speicher) und Compute (SQL-Engine); ein Katalog ist optional.
Lakehouse	Files + Table Format + ACID	Ein Lakehouse setzt auf SQL on Files auf und ergänzt Delta Lake, Iceberg oder Hudi als Table Format. Damit kommen ACID-Transaktionen, Schema-Evolution und Time Travel hinzu. Ein Ordner voller Parquet-Dateien ist SQL-on-Files-fähig, aber noch kein Lakehouse.
External Tables (im Warehouse)	Warehouse-Rahmung um Files	Snowflake External Tables, BigQuery External Tables, Redshift Spectrum, SAP HANA Cloud Remote Sources gegen HDLF: der Katalog des Warehouses bindet Dateien ein, damit sie per SQL abfragbar sind. Das Warehouse bleibt die primäre Query-Umgebung.
Federation	SQL über Remote-Datenbanken	Datenbank-zu-Datenbank-Zugriff (Databricks Lakehouse Federation, Unity Catalog Federation, HANA Cloud Remote Sources gegen Postgres, Oracle, Snowflake). Die Datenquelle ist eine andere Datenbank statt eines Datei-Bestands. Federation und SQL on Files stehen komplementär nebeneinander.
Data Virtualization	Semantischer Virtualisierungs-Layer	Übergeordneter Begriff für virtualisierten Zugriff auf heterogene Quellen (Denodo, Dremio, SAP Datasphere) mit Query-Rewrite und Cache. SQL on Files ist die konkrete technische Ausprägung für Datei-Quellen; Data Virtualization deckt auch relationale, Streaming- und API-Quellen ab.

Die häufigste Abgrenzung verläuft zwischen SQL on Files und Lakehouse, weil dieselbe SQL-Engine beide Muster bedient. Der Bruch liegt beim Table Format: Ohne Delta-Log oder Iceberg-Metadaten-Baum fehlt der SQL-on-Files-Konstellation die Atomicity, Schema-Kontrolle bleibt Sache der Reader, und Deletes oder Updates müssen als Neu-Schreiben ganzer Dateien organisiert werden. Sobald ein Table Format über den Dateien liegt, spricht die Fachwelt von einer Lakehouse-Tabelle, auch wenn die Query technisch weiter SQL auf Parquet-Dateien ausführt.

Die zweite wichtige Abgrenzung ist die zu External Tables im Data Warehouse. External Tables sind eine Katalog-Rahmung des Warehouses um Files, damit sie in der Warehouse-Umgebung als Tabellen sichtbar sind. Der Storage bleibt außen (Objekt-Speicher), der Optimizer und die Query-Engine gehören zum Warehouse. SQL on Files als Zugriffsmuster ist enger und meint typischerweise den direkten Zugriff über eine Lakehouse-Engine wie Spark SQL, Trino oder Databricks SQL, bei dem der Warehouse-Rahmen fehlt.

Beispiel: Ad-hoc-SQL auf Parquet-Klick-Events und der Weg in eine Delta-Tabelle

Ein Data-Engineering-Team landet Klick-Events als Parquet-Dateien in einem S3-Bucket, partitioniert nach event_date. Für eine kurzfristige Ad-hoc-Analyse öffnet ein Analyst ein [Databricks-SQL-Warehouse](/insights/glossar/databricks-sql/) und schreibt SELECT COUNT(*) FROM parquet.\s3://events/klicks/event_date=2026-07-01/\ WHERE campaign_id = 42;. Die Engine liest den Parquet-Footer, wendet Predicate Pushdown auf die Row-Group-Statistiken an, überspringt Row Groups außerhalb des Wertebereichs und liefert das Ergebnis, ohne dass die Dateien zuvor als Tabelle definiert werden mussten. Der Katalog-Eintrag folgt später als External Table im Unity Catalog auf einer [External Location](/insights/glossar/external-locations/), damit Zugriffe zentral berechtigt sind und Lineage entsteht.

Der Übergang von SQL on Files zu einer Lakehouse-Tabelle ist der zweite Teil desselben Beispiels. Sobald das Team parallele Schreib-Jobs, idempotente Updates und Time Travel braucht, wird der Verzeichnis-Bestand über CONVERT TO DELTA in eine Delta-Tabelle umgewandelt oder von Beginn an als Delta geschrieben. Die Parquet-Dateien bleiben physisch am selben Ort; hinzu kommt der _delta_log/-Ordner mit den Transaktions-Commits. Ab diesem Punkt ist die Query technisch immer noch SQL, das Parquet-Dateien liest; das Zugriffsmuster heißt jetzt Lakehouse-Abfrage.