Data

Databricks SQL: Serverless Data Warehousing auf dem Lakehouse 2026

Lädt ein Dashboard langsam, lohnt sich zuerst der Blick unter die Haube: ins Warehouse. Denn in klassischen Architekturen treiben gekoppelte Ressourcen, Concurrency-Kosten und proprietäre Formate die Latenz und die Rechnung.

Databricks SQL beseitigt diese Trennung, indem es ein vollständiges SQL-Analytics-Interface direkt auf dem Lakehouse bereitstellt. Keine Kopien, keine Silos, kein separates Warehouse.

Dieselben Delta-Lake-Tabellen, die eure Data Engineers befüllen, stehen euren BI-Analysten Sekunden später als SQL-Tabellen zur Verfügung, abgesichert durch ACID-Transaktionen, Schema Enforcement und feingranulare Governance über Unity Catalog.

Gespräch vereinbaren
a woman standing before code
TL;DR

Zusammenfassung

  • Databricks SQL ist keine isolierte Warehouse-Lösung, sondern eine SQL-Schicht direkt auf dem offenen Lakehouse ohne Datenkopien oder Silos.
  • Serverless SQL Warehouses starten in Sekunden, skalieren automatisch und sind für die meisten neuen Workloads die empfohlene Wahl.
  • Photon hat die Performance realer Produktions-Workloads in drei Jahren um den Faktor 5 verbessert, automatisch und ohne Query-Rewrites.
  • AI Functions wie ai_classify() und ai_summarize() bringen generative AI direkt in SQL, bis zu 85x schneller als noch vor einem Jahr.
Tagline

Lakehouse Analytics

Lädt ein Dashboard langsam, lohnt sich zuerst der Blick unter die Haube: ins Warehouse. Denn in klassischen Architekturen treiben gekoppelte Ressourcen, Concurrency-Kosten und proprietäre Formate die Latenz und die Rechnung. ML-Engineers und Data Engineers greifen nicht auf dieselben Daten zu wie das BI-Team, weil das Warehouse seine eigenen Kopien vorhält. Das Ergebnis: getrennte Systeme für Analytics und Engineering, doppelte Datenhaltung und steigende Kosten ohne messbaren Gegenwert.

Databricks SQL beseitigt diese Trennung, indem es ein vollständiges SQL-Analytics-Interface direkt auf dem Lakehouse bereitstellt. Keine Kopien, keine Silos, kein separates Warehouse. Dieselben Delta-Lake-Tabellen, die eure Data Engineers befüllen, stehen euren BI-Analysten Sekunden später als SQL-Tabellen zur Verfügung, abgesichert durch ACID-Transaktionen, Schema Enforcement und feingranulare Governance über Unity Catalog. Dieser Guide zeigt, wie Databricks SQL architektonisch funktioniert, welcher Warehouse-Typ zu welchem Workload passt und wo die konkreten Vorteile gegenüber klassischen Cloud Warehouses liegen.

Jetzt Projekt starten
a person working on laptop
Architektur

SQL-Engine auf dem offenen Lakehouse

Photon: Die native Query Engine

Im Kern von Databricks SQL arbeitet Photon, eine von Grund auf in C++ geschriebene, vektorisierte Query Engine. Weil Photon Daten in spaltenbasierten Batches statt zeilenweise verarbeitet, nutzt die Engine moderne CPU-Architekturen (SIMD-Instruktionen, Cache-Hierarchien) maximal aus. Das Resultat: SQL-Queries, die auf identischen Daten mehrfach schneller laufen als mit der klassischen Spark-SQL-Engine.

Die Performance realer Kunden-Workloads hat sich seit 2022 um den Faktor 5 verbessert. Alle Optimierungen wurden automatisch ausgerollt, ohne Query-Rewrites oder manuelles Tuning. Allein im vergangenen Jahr kamen durchschnittlich 40% Performance-Gewinn über alle Produktions-Workloads hinzu. Predictive Query Execution und Photon Vectorized Shuffle liefern weitere 25% ohne Konfigurationsänderung.

Predictive Query Execution statt reaktiver Optimierung

Klassisches Adaptive Query Execution (AQE) in Apache Spark konnte Queries erst nach Abschluss einer Execution Stage umplanen, weshalb Probleme wie Data Skew oder exzessives Spilling oft erst erkannt wurden, wenn der Schaden bereits entstanden war. Predictive Query Execution (PQE) führt stattdessen eine kontinuierliche Feedback-Schleife ein: laufende Tasks werden in Echtzeit auf Metriken wie Spill-Größe und CPU-Auslastung überwacht. Sobald kritische Schwellwerte erreicht sind, stoppt PQE die Stage und plant sie sofort neu, bevor Compute verschwendet wird. Das Ergebnis sind stabilere Laufzeiten und weniger Ausreißer, besonders bei komplexen Joins und Mixed Workloads.

Entkopplung von Compute und Storage

Anders als bei traditionellen Warehouses, die Daten in proprietäre interne Formate importieren, liest Databricks SQL direkt aus Delta Lake auf eurem Object Storage. Diese Entkopplung hat drei konkrete Konsequenzen. Erstens: ihr bezahlt Storage und Compute getrennt, wodurch die Kosten mit dem Datenvolumen linear statt exponentiell wachsen. Zweitens: dieselben Tabellen, die ein Data-Engineering-Job über Declarative Pipelines befüllt, stehen sofort für SQL-Queries zur Verfügung, ohne ETL in ein separates System. Drittens: offene Formate verhindern Vendor Lock-in, da eure Daten jederzeit auch von anderen Engines gelesen werden.

Welche Databricks-SQL-Variante passt

SQL Warehouses: Serverless, Pro und Classic

Welche Databricks-SQL-Variante passt, hängt von Workload, Concurrency und Governance-Anforderungen ab. Es gibt drei Warehouse-Typen, die sich im Betriebsmodell, Feature-Set und in der Kostenstruktur unterscheiden.

Serverless: Sofort verfügbar, vollständig verwaltet

Serverless SQL Warehouses sind die Standardempfehlung für neue Workloads, weil Databricks die gesamte Compute-Infrastruktur verwaltet: Cluster starten in Sekunden statt Minuten, skalieren automatisch mit der Concurrency und stoppen ohne manuelle Konfiguration, sobald keine Queries mehr laufen. Alle neuen Engine-Optimierungen (Predictive Query Execution, Photon Vectorized Shuffle, Zstandard-Kompression) werden automatisch auf Serverless Warehouses ausgerollt.

Der Trade-off liegt im DBU-Preis: Serverless kostet $0,70/DBU, gegenüber $0,55 für Pro und $0,22 für Classic. Entscheidend ist aber der Gesamtkosten-Vergleich, denn durch sofortigen Start, aggressives Auto-Scaling und automatisches Auto-Stop zahlt ihr nur für tatsächlich verbrauchte Compute-Sekunden. Bei Workloads mit variablem Traffic (Ad-hoc-Analysen, Dashboard-Peaks) ist Serverless dadurch oft günstiger als ein dauerhaft laufendes Classic Warehouse, das in Leerlaufzeiten weiter DBUs verbrennt.

Pro: Der Mittelweg mit erweiterten Features

Pro Warehouses bieten das gleiche Feature-Set wie Serverless (Photon, AI Functions, Intelligent Workload Management), laufen aber auf kundenseitig provisionierter Infrastruktur. Die Startzeit fällt länger aus (Minuten statt Sekunden), dafür liegt der DBU-Preis 20% unter Serverless. Pro eignet sich für vorhersagbare Workloads mit stabiler Concurrency, etwa als dediziertes BI-Warehouse für tägliche Reports, das morgens hochfährt und abends stoppt.

Classic: Niedrigster DBU-Preis, eingeschränktes Feature-Set

Classic Warehouses sind mit $0,22/DBU die kostengünstigste Option, verzichten aber auf zentrale Capabilities: keine AI Functions, kein Intelligent Workload Management, keine automatischen Engine-Updates. Weil weder interaktive Latenz noch Feature-Parität gegeben sind, eignet sich Classic nur noch für extrem stabile, vorhersagbare Batch-Workloads. Für die meisten Organisationen ist Classic ein Auslaufmodell.

Wann welcher Typ?

Wer heute ein neues SQL Warehouse aufsetzt, startet mit Serverless. Wer vorhersagbare Workloads mit stabilem Volumen hat, evaluiert Pro. Classic bleibt für Bestandsworkloads, die keine neuen Features brauchen.

Auto-Scaling: Wie SQL Warehouses mit der Last wachsen

Serverless Warehouses skalieren über Intelligent Workload Management (IWM): ein ML-Modell schätzt den Ressourcenbedarf jeder eingehenden Query, prüft die verfügbare Kapazität und provisioniert bei steigender Queue-Tiefe automatisch zusätzliche Cluster. Sinkt die Last, fährt IWM die Cluster ebenso schnell wieder herunter. Ihr konfiguriert lediglich die maximale Cluster-Anzahl – den Rest übernimmt die Plattform.

Bei Pro und Classic Warehouses läuft das Scaling nach einem regelbasierten Modell: ab 2–6 Minuten geschätzter Query-Last wird ein Cluster hinzugefügt, ab 6–12 Minuten zwei, und so weiter. Wartet eine Query länger als 5 Minuten in der Queue, skaliert das Warehouse hoch. Bleibt die Last 15 Minuten niedrig, wird wieder auf das Minimum reduziert. Die Faustregel für die Kapazitätsplanung: ein Cluster pro 10 gleichzeitige Queries.

Auto-Stop: 1 Minute statt 5 über Terraform und API

Im UI liegt das Minimum für Auto-Stop bei 5 Minuten (Serverless) bzw. 10 Minuten (Pro/Classic). Wer den Leerlauf-Verbrauch konsequent minimieren will, setzt den Wert über die SQL Warehouses API oder Terraform auf 1 Minute – das ist der niedrigste erlaubte Wert über die API. Bei einem Serverless Warehouse mit 1-Minute-Auto-Stop und Sekunden-Startzeit zahlt ihr effektiv nur für aktive Query-Zeit. Für Infrastructure-as-Code-Teams ist das ein relevanter FinOps-Hebel, der sich über Terraform-Variablen zentral für alle Warehouses steuern lässt.

Wo SQL Warehouses überall zum Einsatz kommen

SQL Warehouses sind nicht nur die Compute-Schicht für manuelle SQL-Queries, sondern der zentrale Execution Layer für zahlreiche Databricks-Oberflächen:

  • SQL Editor: Interaktive Query-Entwicklung und Ad-hoc-Analysen
  • AI/BI Dashboards: Visualisierungen und Reports, die direkt auf SQL Warehouses laufen
  • AI/BI Genie Spaces: Natürlichsprachliche Fragen, die Genie in SQL übersetzt und auf dem Warehouse ausführt
  • Alerts: Automatisierte Benachrichtigungen bei Schwellwertüberschreitungen, getriggert durch geplante SQL-Queries
  • Notebooks: SQL-Zellen in Databricks Notebooks nutzen SQL Warehouses als Compute-Backend
  • Catalog Explorer: Datenvorschauen und Profiling in Unity Catalog laufen auf dem Default SQL Warehouse
  • Partner-Integrationen: BI-Tools wie Power BI, Tableau oder dbt verbinden sich über SQL Warehouses per JDBC/ODBC

Jedes dieser Einsatzgebiete teilt sich die gleiche Governance (Unity Catalog), die gleichen Performance-Optimierungen (Photon, PQE) und das gleiche Kostenmodell. Wer ein Serverless SQL Warehouse als Workspace-Default setzt, gibt allen Teams – von BI-Analysten über Data Engineers bis zu Business-Nutzern mit Genie – eine gemeinsame, sofort verfügbare Compute-Ressource.

‍

SQL Editor

SQL Editor und Entwicklererfahrung

ANSI-SQL; kein proprietärer Dialekt

Databricks SQL spricht standardkonformes ANSI SQL. Wer SELECT, JOIN, GROUP BY, Window Functions oder CTEs kennt, schreibt sofort produktive Queries – ohne neue Syntax zu lernen. Das senkt die Einstiegshürde für BI-Analysten und Data Engineers gleichermaßen, und bestehende SQL-Skripte aus anderen Warehouses lassen sich in den meisten Fällen ohne Anpassung migrieren.

Integrierter SQL Editor mit AI-Unterstützung

Databricks bringt einen vollwertigen SQL Editor direkt in der Web-Oberfläche mit: Syntax-Highlighting, kontextabhängiges Autocomplete (erkennt Tabellen, Spalten und Aliase aus Unity Catalog), Multi-Tab-Editing und integrierte Visualisierungen. Ergebnisse lassen sich direkt als Chart rendern oder per Klick in ein AI/BI Dashboard überführen.

Seit dem neuen Editor kommt der Databricks Assistant als AI-Copilot dazu: er generiert SQL aus natürlichsprachlichen Beschreibungen, optimiert bestehende Queries über den /optimize-Befehl und erklärt komplexe Statements. Für komplexere Aufgaben gibt es Genie Code, einen autonomen KI-Agenten, der mehrstufige Analysen selbstständig durchführt. Dazu kommen Echtzeit-Kollaboration (mehrere Nutzer arbeiten gleichzeitig an derselben Query), Code-Kommentare und Versionierung – Features, die man sonst nur aus dedizierten IDEs kennt. (Siehe Aufnahme unterhalb des Textes)

Unity Catalog als zentraler Datenkatalog

Der SQL Editor ist nativ in Unity Catalog integriert: der Schema-Browser zeigt alle Catalogs, Schemas und Tabellen, auf die der Nutzer Zugriff hat – mit Spaltentypen, Beschreibungen und Lineage-Informationen. Ihr navigiert den gesamten Datenkatalog direkt im Editor, ohne zwischen Tools wechseln zu müssen. Unity Catalog gilt plattformweit: BI-Analysten im SQL Editor sehen exakt dieselben Tabellen und Berechtigungen wie Data Engineers in Notebooks oder ML-Engineers in Feature Stores.

AI Functions

Generative AI direkt in SQL

Databricks SQL bringt Large Language Models direkt in die SQL-Schicht: über native AI Functions lassen sich Klassifikation, Zusammenfassung, Übersetzung und Dokumentenverarbeitung als SQL-Funktionen aufrufen – ohne separates Model-Deployment und ohne Python-Code.

Die wichtigsten Funktionen

Als universelle Schnittstelle dient ai_query(): die Funktion sendet beliebige Prompts an Foundation Models (Llama, DBRX, Claude, GPT) und gibt das Ergebnis als SQL-Spalte zurück. Daneben stehen spezialisierte Funktionen bereit, darunter ai_classify() für Kategorisierung, ai_summarize() für Textzusammenfassungen, ai_translate() für Übersetzungen, ai_extract() für strukturierte Extraktion aus Freitext und ai_parse_document() für die Verarbeitung unstrukturierter Dokumente.

Performance: Von Stunden auf Minuten

Die Batch-optimierte Infrastruktur hinter den AI Functions hat deren Performance drastisch verbessert: Funktionen wie ai_classify, ai_summarize und ai_translate laufen bis zu 85x schneller als noch zu Jahresbeginn. Da ai_parse_document spezialisierte Modelle auf Databricks Model Serving nutzt, erreicht die Funktion bis zu 30x höheren Durchsatz als generische LLM-Alternativen.

Performance

Was das in der Praxis bedeutet

Statt eine separate NLP-Pipeline zu bauen, um Kundenfeedback zu klassifizieren, reicht ein SQL-Statement:

SQL

SELECT
  feedback_id,
  feedback_text,
  ai_classify(feedback_text, ARRAY('Beschwerde', 'Lob', 'Feature-Request', 'Bug-Report')) AS kategorie
FROM customer_feedback
WHERE received_date >= current_date() - INTERVAL 7 DAYS
Performance

Dokumente verarbeiten mit ai_parse_document

ai_parse_document() extrahiert strukturierte Daten aus PDFs, Bildern und gescannten Dokumenten – direkt in SQL. Die Funktion nutzt spezialisierte Modelle auf Databricks Model Serving und erreicht dadurch bis zu 30x höheren Durchsatz als generische LLM-Alternativen. Ein typischer Anwendungsfall: eingehende Rechnungen aus einem Cloud-Storage-Pfad parsen und die Ergebnisse als strukturierte Tabelle ablegen.

Custom Models über ai_query

Wer domänenspezifische Anforderungen hat, die mit den eingebauten Funktionen nicht abgedeckt sind, nutzt ai_query() als universelle Schnittstelle. Die Funktion sendet beliebige Prompts an jedes Modell, das auf Databricks Model Serving läuft – Foundation Models wie Llama, DBRX oder Claude, aber auch eigene Fine-Tuned-Modelle, die ihr über MLflow registriert habt.

Das macht den Unterschied zu generischen AI-Integrationen: ihr seid nicht auf vorgefertigte Funktionen beschränkt, sondern könnt jedes Modell – ob Foundation oder Custom – als SQL-Funktion aufrufen. BI-Analysten, die bisher auf Data-Science-Kolleginnen und -Kollegen warten mussten, um Textdaten auszuwerten, rufen AI-Modelle jetzt direkt als SQL-Funktion auf.

Web developer, tablet and coding in office for software, system or website update advice.
Performance

Governance und Sicherheit mit Unity Catalog

Governance, Zugriffssteuerung und Compliance in Databricks SQL laufen über Unity Catalog. Jede Tabelle, jede View und jedes Dashboard unterliegt demselben Berechtigungsmodell – mit Row-Level Security, Column Masking und feingranularer Zugriffssteuerung.

Performance trotz Governance

In klassischen Warehouse-Systemen verlangsamen Berechtigungsprüfungen, Metadata-Lookups und Lineage-Tracking die Queries spürbar, besonders bei interaktiven Workloads. Databricks hat die End-to-End-Latenz von Unity Catalog um den Faktor 10 reduziert, sodass Dashboards responsiv bleiben, auch wenn feingranulare Zugriffskontrollen auf jeder Tabelle aktiv sind. Ihr müsst nicht zwischen starker Governance und schnellen Queries wählen.

Materialized Views und Metric Views

Databricks SQL unterstützt Materialized Views als Unity-Catalog-Managed-Tables, die Query-Ergebnisse physisch speichern und inkrementell aktualisieren. Für häufig abgefragte Aggregationen (tägliche Umsätze, KPI-Rollups) eliminieren sie redundante Berechnungen und beschleunigen Dashboard-Loads erheblich.

Metric Views gehen einen Schritt weiter, indem sie Business-Metriken (KPIs, Measures, Dimensionen) zu First-Class-Assets in Unity Catalog machen. Eine Metrik wie „Monthly Recurring Revenue" wird einmal definiert und ist dann konsistent in SQL-Queries, Dashboards, Notebooks und AI-Workloads nutzbar. Damit löst Databricks ein Problem, das in klassischen Warehouse-Setups chronisch ist: unterschiedliche Metrik-Definitionen in verschiedenen Tools, die zu widersprüchlichen Zahlen führen.

Databricks SQL im Vergleich:

Snowflake, BigQuery, Fabric

Die Frage „Databricks SQL oder Snowflake?" kommt bei jeder Plattformentscheidung auf den Tisch. Die Antwort hängt weniger von einzelnen Benchmarks ab als davon, was eure Datenplattform jenseits von SQL leisten muss.

Databricks SQL vs. Snowflake

In ETL-Benchmarks (TPC-DI) zeigt Databricks SQL bis zu 2,8x kürzere Laufzeiten bei 3,6x besseren Gesamtkosten gegenüber Snowflake Gen2 Warehouses (Databricks SQL SME). Der Grund liegt in der Architektur: Photons vektorisierte C++-Engine ist für schwere Transformationen, Joins und Shuffles optimiert, während Snowflakes Stärke bei einfachen, hochparallelen BI-Queries mit breiter Concurrency liegt.

Der strategische Unterschied geht aber über Performance hinaus, denn Databricks SQL operiert auf denselben Daten und derselben Governance wie eure Data-Engineering- und ML-Workloads. Bei Snowflake dagegen sind Analytics und Engineering getrennte Welten mit getrennten Compute-Pools und oft getrennten Kopien der Daten. Für eine detaillierte Gegenüberstellung empfehlen wir unseren Databricks vs. Snowflake Vergleich.

Databricks SQL vs. Microsoft Fabric

Microsoft Fabric positioniert sich als integrierte Analytics-Plattform für Organisationen im Microsoft-Ökosystem: der SQL Analytics Endpoint bietet T-SQL-Kompatibilität und native Power-BI-Integration, was für reine Microsoft-Shops attraktiv ist. Databricks SQL ist Cloud-agnostisch (AWS, Azure, GCP), bietet mit Photon die leistungsstärkere Engine für schwere Workloads und verbindet SQL direkt mit Data Engineering und AI auf derselben Plattform. Einen ausführlichen Vergleich findet ihr in unserem Databricks vs. Fabric Guide.

Wann Databricks SQL die richtige Wahl ist

Databricks SQL ist die stärkere Option, wenn eure Plattform mehr als nur SQL-Analytics leisten muss: Data Engineering, ML/AI und SQL auf denselben Daten, mit derselben Governance, ohne Datenkopien. Wenn eure Anforderung ausschließlich einfache BI-Queries mit maximaler Concurrency bei minimalem Engineering-Aufwand ist und ihr keine Engineering- oder ML-Workloads plant, bleibt Snowflake eine valide Alternative.

Tagline

Typische Fehler und wie ihr sie vermeidet

Warehouse-Sizing nach Gefühl statt nach Workload

Ein häufiger Fehler: das SQL Warehouse wird „sicherheitshalber" eine Nummer größer provisioniert, weil ja „Peaks kommen könnten". Bei Serverless Warehouses ist das irrelevant, denn die skalieren automatisch. Bei Pro/Classic Warehouses hingegen führt Oversizing zu dauerhaft erhöhtem DBU-Verbrauch, ohne dass die Queries schneller werden, weil nicht jede Query von mehr Compute profitiert. Failure Mode: Ein Large Pro Warehouse, das für Spitzen provisioniert wurde, läuft 80% der Zeit mit 20% Auslastung. Fix: Startet mit einem Small Warehouse, nutzt die Query History für tatsächliche Ressourcenauslastung und skaliert basierend auf Daten statt auf Vermutungen. Wer FinOps systematisch angehen will, findet in unserem FinOps-Service den passenden Rahmen.

Classic Warehouses im Dauerbetrieb

Classic Warehouses mit deaktiviertem Auto-Stop sind der teuerste Fehler, den wir in der Praxis sehen. Ein Medium Classic Warehouse, das 24/7 läuft, verbraucht auch dann DBUs, wenn nachts und am Wochenende keine einzige Query ausgeführt wird. Bei 168 Stunden pro Woche und einer realistischen Nutzung von 40 Stunden zahlt ihr 75% des Compute für Leerlauf. Fix: Entweder aggressives Auto-Stop (5-10 Minuten Idle-Timeout) konfigurieren oder direkt auf Serverless migrieren, wo Leerlauf per Definition keine Kosten erzeugt.

AI Functions ohne Batch-Optimierung

AI Functions wie `ai_classify` oder `ai_summarize` liefern starke Ergebnisse, sind aber nicht kostenlos. Wer sie auf Millionen von Rows in einer Echtzeit-Query ausführt statt als geplanten Batch-Job, erzeugt unnötigerweise hohe Model-Serving-Kosten und lange Laufzeiten. Fix: AI Functions als Materialized View oder als geplanten Job ausführen, der die Ergebnisse in eine Zieltabelle schreibt. Die nachgelagerten Dashboards lesen dann die vorberechneten Ergebnisse, nicht die Live-AI-Calls.

Jetzt Projekt starten
Performance-Optimierung

Was Databricks SQL automatisch macht

Table Maintenance, Query-Priorisierung und Kompression erfordern in klassischen Warehouses manuelles Tuning. Databricks SQL übernimmt diese Aufgaben zunehmend automatisch, was den operativen Aufwand für Data Engineers deutlich reduziert.

Predictive Optimization

Predictive Optimization analysiert eure Tabellen kontinuierlich und führt automatisch `OPTIMIZE`, `VACUUM` und Statistik-Updates durch, ohne dass ihr Maintenance-Jobs schedulen müsst. Tabellen bleiben dadurch performant, ohne dass sich ein Data Engineer aktiv darum kümmern muss.

Intelligent Workload Management

Bei hoher Concurrency priorisiert Intelligent Workload Management (IWM) Queries automatisch nach ihrer erwarteten Laufzeit und Ressourcenanforderung, sodass kurze Dashboard-Queries bevorzugt behandelt werden und interaktive Nutzer nicht hinter schweren ETL-Queries warten müssen. In klassischen Warehouses muss diese Priorisierung manuell über Queues und Priority-Regeln konfiguriert werden.

Zstandard-Kompression

Alle neuen Unity-Catalog-Managed-Tables verwenden standardmäßig Zstandard-Kompression, die bis zu 40% Storage-Kosten spart, ohne die Query-Performance zu beeinträchtigen (Databricks). Für bestehende Tabellen stellt Databricks Migrations-Tooling bereit, und besonders bei großen Fact-Tables und langlebigen Datasets macht sich der Unterschied deutlich bemerkbar.

Foto von drei Personen, die vor einem Computer sitzen
Auf den Punkt gebracht

Fazit

Databricks SQL ist kein klassisches Data Warehouse, das neben eurer Datenplattform existiert, sondern die SQL-Schicht auf dem Lakehouse: dieselben Daten, dieselbe Governance, dasselbe Ökosystem wie eure Data-Engineering- und ML-Workloads.

Die wichtigsten Takeaways:

  1. Eine Engine, alle Workloads: Photon liefert 5x Performance-Gewinn über drei Jahre, automatisch und ohne manuelles Tuning. BI-Dashboards, ETL, Spatial Analytics und AI Functions laufen auf derselben Engine.
  2. Serverless als Standard: Sofortiger Start, automatisches Scaling, kein Leerlauf-Compute. Für die meisten Workloads ist Serverless SQL die richtige Wahl.
  3. AI als SQL-Funktion: ai_query, ai_classify, ai_summarize bringen generative AI direkt in eure Analytics, ohne separate Pipelines. Batch-optimiert bis zu 85x schneller als noch vor einem Jahr.
  4. Governance ohne Kompromisse: Unity Catalog sichert feingranulare Zugriffskontrolle bei 10x niedrigerer Latenz. Metric Views machen Business-Metriken zu einem Single Point of Truth.
  5. Offene Formate, kein Lock-in: Eure Daten bleiben in Delta Lake auf eurem Object Storage. Kein proprietäres Format, keine versteckten Exportkosten.

Databricks SQL produktiv einsetzen

Wenn ihr Databricks SQL als Analytics-Engine einführen wollt und offene Fragen habt: hilft ein kurzes Gespräch mehr als Wochen Eigenrecherche.

Make an appointment
Foto: Alex

Answers to your questions

Clarify open questions

Was ist Databricks SQL?

Databricks SQL ist die SQL-Analytics-Schicht der Databricks-Plattform. Sie stellt serverlose SQL Warehouses bereit, die auf der Photon Query Engine laufen und direkt auf Delta-Lake-Tabellen im offenen Lakehouse zugreifen. Databricks SQL ermöglicht BI-Reporting, Ad-hoc-Analysen und AI-gestützte Analytics, ohne Datenkopien in ein separates Warehouse.

Was kostet Databricks SQL?

Databricks SQL wird in Databricks Units (DBUs) abgerechnet. Auf AWS liegen die Preise bei $0,22/DBU (Classic), $0,55/DBU (Pro) und $0,70/DBU (Serverless). Beim Serverless-Modell sind die Cloud-Compute-Kosten bereits im DBU-Preis enthalten, bei Classic und Pro kommen die Infrastrukturkosten des Cloud-Providers hinzu. Die tatsächlichen Gesamtkosten hängen von Warehouse-Größe, Laufzeit und Concurrency ab.

Wann Databricks SQL statt Snowflake?

Databricks SQL ist die bessere Wahl, wenn eure Datenplattform neben SQL-Analytics auch Data Engineering, ML und AI abdecken muss, denn alle Workloads teilen sich dieselben Daten und dieselbe Governance. Snowflake bleibt stark bei reinen BI-Szenarien mit hoher Concurrency und minimalem Engineering-Overhead. Der Trend geht zunehmend zu Databricks SQL, da die Photon Engine klassische BI-Workloads performant abdeckt und gleichzeitig AI Functions und Engineering-Workloads auf derselben Plattform ermöglicht.

Was ist der Unterschied zwischen Serverless, Pro und Classic SQL Warehouses?

Serverless Warehouses starten in Sekunden, skalieren automatisch und erhalten alle Engine-Updates sofort, kosten aber $0,70/DBU. Pro Warehouses bieten dasselbe Feature-Set auf kundenseitig verwalteter Infrastruktur für $0,55/DBU, starten aber langsamer. Classic Warehouses sind am günstigsten ($0,22/DBU), verzichten aber auf AI Functions und Intelligent Workload Management.

Was sind AI Functions in Databricks SQL?

AI Functions sind native SQL-Functions, die Large Language Models direkt aus SQL-Queries aufrufen. ai_query() ist die universelle Funktion für beliebige Prompts, daneben gibt es spezialisierte Funktionen wie ai_classify(), ai_summarize(), ai_translate() und ai_parse_document(). Sie ermöglichen Text-Analytics, Dokumentenverarbeitung und Klassifikation direkt in SQL, ohne Python-Code oder separate ML-Pipelines.

Wie schnell ist Databricks SQL im Vergleich?

Databricks SQL hat die Performance realer Produktions-Workloads in drei Jahren um den Faktor 5 verbessert. In ETL-Benchmarks (TPC-DI) erreicht die Engine bis zu 2,8x kürzere Laufzeiten als Snowflake Gen2 bei 3,6x besseren Gesamtkosten. AI Functions laufen durch Batch-Optimierung bis zu 85x schneller als noch vor einem Jahr, während Spatial-SQL-Queries durch R-Tree-Indexing und optimierte Joins bis zu 17x beschleunigt wurden.