Databricks Apps: Definition, Abgrenzung, Beispiele

Databricks Apps ist der 2024 in Public Preview eingeführte und seit Mai 2025 allgemein verfügbare App-Service der Databricks Data Intelligence Platform. Er hostet interne Web-Anwendungen (etwa in Streamlit, Dash, Gradio, Flask oder FastAPI) direkt im Databricks-Workspace, mit integriertem Zugriff auf Unity Catalog, Model Serving Endpoints und Genie.

Was sind Databricks Apps?

Databricks Apps ist ein vollständig verwalteter App-Service innerhalb der Databricks-Plattform. Der Dienst betreibt interne Web-Anwendungen (also Anwendungen mit einer Benutzeroberfläche im Browser, die nur angemeldete Personen der Organisation nutzen) auf einer serverlosen Compute-Basis. Ein eigener Webserver, eine eigene Container-Plattform (wie Kubernetes) oder ein separates Hosting-Angebot sind nicht notwendig. Als Entwicklungs-Frameworks kommen die verbreiteten Python-Web-Frameworks Streamlit, Dash, Gradio, Flask und FastAPI zum Einsatz; ergänzend werden Node.js-Frameworks wie React und Next.js unterstützt. Die App wird als Projektordner mit dem Anwendungs-Code und einer YAML-Konfiguration in einen Workspace-Ordner geladen und über die Databricks-Konsole oder die Databricks-CLI bereitgestellt.

Der Dienst ist seit November 2024 als Public Preview verfügbar und seit Mai 2025 allgemein verfügbar (GA) in über 28 Regionen auf AWS, Azure und Google Cloud. Voraussetzung ist ein Premium-Workspace; einzelne Cloud-Region-Kombinationen erfordern zusätzlich die aktivierte Serverless-Option im Workspace.

Der Anschluss an die restliche Plattform läuft über vier Bausteine. Die Anmeldung erfolgt über den bestehenden Databricks-Account und damit über den angebundenen Cloud-Identity-Provider (Microsoft Entra ID, Okta, AWS IAM Identity Center). Der Datenzugriff läuft transitiv über Unity Catalog, sodass Berechtigungen, Row-Level Security, Column Masking und Lineage auch für App-Zugriffe gelten. Modell-Aufrufe erfolgen über Model Serving Endpoints, Text-zu-SQL-Fragen über Genie und SQL-Abfragen über ein SQL Warehouse. Ein zusätzliches Berechtigungs-System auf App-Ebene entfällt.

Zwei Identitäts-Modi unterscheiden, in wessen Namen die App auf Daten und Modelle zugreift. Im On-Behalf-of-User-Modus (OBO) handelt die App im Kontext des angemeldeten Nutzers; Unity-Catalog-Berechtigungen filtern die Datensicht pro Person, und die Audit-Spur weist den Nutzer als Aufrufer aus. Im App Service Principal-Modus handelt die App unter einem technischen Konto; alle Nutzer sehen dieselbe Datenteilmenge, für die das Service-Konto berechtigt ist. Die Entscheidung zwischen beiden Modi ist eine Governance-Entscheidung, die Datenzugriff und Auditability festlegt.

Der Begriff existiert, weil interne Fach-Anwendungen mit direktem Zugriff auf Lakehouse-Daten bislang auf separater Hosting-Infrastruktur (eigene Server, Container-Plattformen, Streamlit Community Cloud) mit eigener Login-Strecke und eigenem Berechtigungs-Layer liefen. Der App-Service verlagert die Runtime in die Plattform selbst und erbt Identität, Berechtigungen und Audit-Trail. Damit besetzt Databricks Apps neben AI/BI Dashboards (Reporting) und Genie (Text-to-SQL) einen dritten Konsum-Modus auf denselben Daten: die interaktive Custom-Anwendung.

Abgrenzung zu Notebooks, AI/BI Dashboards, Model Serving und externem Hosting

Der Begriff wird häufig mit benachbarten Databricks-Komponenten oder mit externen Hosting-Angeboten vermischt. Die Abgrenzung verläuft entlang zweier Achsen: Rolle im Nutzungs-Kontext (Entwicklung, Reporting, API, App-Runtime) und Position gegenüber externen Alternativen.

Begriff	Achse	Kernunterschied
Databricks Notebooks	Nutzungs-Kontext	Notebooks sind die interaktive Entwicklungs- und Analyse-Umgebung für einen Autor; ohne UI-Runtime für viele Nutzer, ohne bereitstellbare Web-Oberfläche. Databricks Apps ist die bereitgestellte Web-Anwendung für viele Nutzer. Ein Notebook kann als Entwicklungs-Vorstufe dienen, der Betrieb geht dann in eine App über.
AI/BI Dashboards	Nutzungs-Kontext	AI/BI Dashboards ist die native BI-Komponente mit vorgefertigten Visualisierungen auf SQL-Abfragen, DatabricksIQ-Insights und Genie-Anschluss. Databricks Apps liefert Custom-Layouts, Formulare, Rückschreib-Aktionen und komplexe Interaktionen. Für aggregierte Kennzahlen-Berichte ist ein Dashboard schneller gebaut, für Anwendungen mit Rückschreib- oder Freitext-Logik trägt eine App.
Model Serving	Stack-Position	Model Serving stellt trainierte Modelle als API-Endpunkt bereit; ein Aufruf liefert JSON über HTTP oder gRPC ohne eigene Oberfläche. Databricks Apps baut die Web-Oberfläche darüber und ruft Model-Serving-Endpoints als Backend auf. Beide Bausteine sind komplementär.
Streamlit Community Cloud, Heroku, eigene Container	Hosting-Ort	Externes Hosting mit eigenem Login-Weg, eigener Zugriffs-Verwaltung und ohne native Unity-Catalog-Integration. Der Zugriff auf Databricks-Daten braucht dort ein Personal Access Token oder einen OAuth-Client, das getrennt gepflegt wird. Databricks Apps läuft innerhalb der Plattform und erbt Identität, Berechtigungen und Audit-Trail.
Insight Apps (Kategorie)	Begriffs-Ebene	Insight Apps ist die Anwendungs-Kategorie (embedded Analytics mit eingebetteter Aktion). Databricks Apps ist eine konkrete Runtime für diese Kategorie neben SAP Insight Apps in der Business Data Cloud und externen Streamlit/Dash-Deployments.

Wichtig ist die Trennung zwischen Databricks Apps und den zwei benachbarten Konsum-Modi. AI/BI Dashboards zielt auf vorbereitete Reports über SQL-Abfragen; die Erweiterbarkeit endet, sobald Rückschreib-Logik, komplexe Formulare oder Freitext-Eingaben ins Spiel kommen. Model Serving zielt auf Modell-Aufrufe als API; die Erweiterbarkeit endet, sobald eine Oberfläche für Fachanwender gefragt ist. Databricks Apps besetzt die Custom-UI-Position dazwischen und ruft die anderen beiden Bausteine als Backend auf.

Gegenüber externem Hosting reduziert sich der Vergleich auf Governance und Betriebsaufwand. Eine Streamlit-App auf Streamlit Community Cloud, Heroku oder in einem eigenen Kubernetes-Cluster funktioniert technisch identisch, benötigt aber einen separaten Login-Weg, ein separates Secret-Management für Databricks-Zugriffe und einen separaten Audit-Layer. Ein Databricks-App-Deployment übernimmt diese Aufgaben aus der Plattform.

Beispiel: Nachfrageprognose-App mit Rückschreib-Logik

Eine Vertriebssteuerung im Handel betreibt eine Nachfrageprognose je Region und Warengruppe. Die aggregierten Prognosen liegen im Gold-Layer als View prod.sales.forecast_regions im Unity Catalog. Ein Data-Science-Team hat ein Prognose-Modell trainiert und über Databricks Model Serving als Endpoint demand-forecast-v3 bereitgestellt.

Eine Streamlit-App im Databricks-Workspace kombiniert beide Bausteine. Die App liest die Prognose-View, stellt die Zahlen als Tabelle und Zeitreihen-Chart dar und öffnet eine Editier-Spalte für manuelle Korrekturen. Auf Wunsch ruft die App den Model-Serving-Endpoint für ein Ad-hoc-Szenario („Wie ändert sich die Prognose, wenn der Preis um fünf Prozent steigt?") und zeigt das Ergebnis neben dem Basis-Wert an. Manuelle Korrekturen werden per MERGE INTO in eine Delta-Tabelle prod.sales.forecast_manual_overrides zurückgeschrieben, mit Zeitstempel, Nutzer-Name und Kommentar.

Die App läuft im On-Behalf-of-User-Modus. Der Zugriff auf die View prod.sales.forecast_regions unterliegt einer Row-Level-Security-Regel im Unity Catalog, die Regionen an Vertriebsgruppen bindet; ein Regional-Verantwortlicher sieht nur die eigene Region, eine zentrale Rolle sieht alle Regionen. Der Aufruf des Model-Serving-Endpoints und der Schreibzugriff auf forecast_manual_overrides sind über dieselben Unity-Catalog-Grants berechtigt. system.access.audit protokolliert jeden Lese- und Schreibzugriff mit dem Namen des angemeldeten Nutzers, nicht mit einer generischen App-Identität.

Das Beispiel zeigt die typische Architekturposition: eine Datenschicht (Views und Tabellen im Unity Catalog), eine Modell-Schicht (Model Serving Endpoint), eine App-Schicht (Streamlit auf Databricks Apps) und darüber die Konsum-Oberfläche (Databricks-Account-Login, direkter Aufruf im Browser). Login, Berechtigungen, Modell-Aufruf und Audit-Trail laufen in einer gemeinsamen Governance-Klammer.