Databricks Apps: Best Practices von der ersten App bis zum stabilen Betrieb

Jemand aus dem Vertrieb hat an einem Nachmittag mit einem KI-Werkzeug eine App gebaut, die gut aussieht und das ganze Team möchte sie nutzen. Das Problem? Sie holt ihre Zahlen direkt aus dem Produktivsystem.

Databricks Apps ist ein serverloser Dienst, mit dem Unternehmen eigene Daten- und KI-Anwendungen direkt in ihrem Databricks-Arbeitsbereich betreiben können, ohne dazu eigene Server oder separate Zugangsverwaltung zu benötigen.

Das Kernprodukt ist allgemein verfügbar, Apps laufen mit Python- oder Node.js-Frameworks wie Streamlit oder React und greifen über Unity Catalog auf die freigegebenen Daten zu. Produktionsreif wird eine App jedoch erst mit klaren Identitäten, getesteter Last, laufender Überwachung und einem festen Kostenrahmen.

Der Wunsch der Fachbereiche, sich eigene Werkzeuge zu bauen, ist berechtigt, und KI macht das heute für fast jeden möglich. Gefährlich wird es aber, sobald niemand weiß, wie sich diese App anmeldet, wer welche Daten sieht und wer sie in drei Monaten noch betreut.

Apps auf Databricks sind eine Antwort darauf. Sie laufen direkt neben den Daten, und es gelten dieselben Regeln wie für den Rest der Plattform. Dieser Ratgeber zeigt, wie Sie Apps einführen, steuern, bauen und stabil betreiben, entlang der Funktionen, die Databricks 2026 dafür veröffentlicht hat.

Was Databricks Apps sind und wofür sie sich eignen

Eine App auf Databricks ist eine Weboberfläche, die auf serverloser Rechenleistung der Plattform läuft und eine eigene Adresse bekommt. Darüber hinaus kümmert sich Databricks um Server, Anmeldung und Bereitstellung. Laut offizieller Dokumentation laufen dort Python-Anwendungen mit Streamlit, Dash oder Gradio ebenso wie Node.js-Anwendungen mit React, Angular, Svelte oder Express.

Seit der allgemeinen Verfügbarkeit ist das Kernprodukt für den Produktiveinsatz freigegeben. Neue Bausteine befinden sich allerdings noch in der Beta-Phase (Stand Oktober 2026). Dazu gehören App Spaces, Genie App Builder und die horizontale Skalierung.

Der Nutzen liegt im Zusammenspiel. Während die App SQL Warehouses, Modelle, Jobs, Genie Agents (früher Genie Spaces) oder Lakebase aufruft, kommen die Rechte dafür aus Unity Catalog. Sie bauen also keine zweite Zugangsverwaltung neben Ihrer Datenplattform auf.

Typische Einsatzfälle für eine App sind beispielsweise Freigabe- und Korrekturoberflächen, Formulare zur Datenerfassung, interne Wissens- oder Chat-Anwendungen und Planungswerkzeuge für den Fachbereich. Gleichzeitig wird nicht für jeden Bedarf eine eigene App benötigt. Oft reicht auch ein Werkzeug, das Databricks bereits mitbringt:

Die Lücke, die Apps schließen, ist real. Laut Bitkom (2025) gaben 60 Prozent von 605 befragten deutschen Unternehmen an, das Potenzial ihrer Daten nur wenig oder gar nicht zu nutzen. Oft fehlt dabei nicht das Wissen über die Daten, sondern der Weg vom Lakehouse zum Arbeitsplatz der Fachleute.

Einführen: Mit dem richtigen ersten Anwendungsfall starten

Die erste App entscheidet, ob weitere folgen. Dafür sollten Sie zunächst einen Fall wählen, der im Fachbereich sichtbar ist, aber nicht das Tagesgeschäft lahmlegt, wenn er einmal hakt. Gut geeignet ist eine Oberfläche, die vorhandene Daten liest und Freigaben oder Kommentare erfasst. Schreibende, geschäftskritische Anwendungen sollten später dazukommen.

Je nach Lage im Unternehmen bieten sich drei Einstiege an:

• Steuerung zuerst: Fürchtet Ihre IT vor allem den Wildwuchs an KI-Werkzeugen und App-Baukästen? Dann ist ein geregelter App-Ort auf der eigenen Datenplattform das stärkste Argument.
• Ein sichtbarer Anwendungsfall: Wenn die Diskussion festhängt, konzentrieren Sie sich auf einen einzigen wertvollen Ablauf und bauen ihn vollständig auf Databricks. Das Ergebnis überzeugt mehr als jede Folie.
• Fachbereiche befähigen: Wenn die IT eher abwartet, helfen Schulungen oder ein interner Hackathon mit einzelnen Abteilungen. Wer selbst eine App gebaut hat, fragt aktiv nach der Freigabe.

Vor dem Start sollten zuerst folgende Punkte geklärt sein:

1. Ist der App-Dienst in der Cloud-Region Ihres Arbeitsbereichs verfügbar? Databricks führt dafür eine Übersicht unterstützter Regionen.
2. Liegen die benötigten Daten in Unity Catalog?
3. Gibt es getrennte Umgebungen für Entwicklung, Test und Produktion?
4. Und haben Sie je App einen fachlichen und einen technischen Verantwortlichen benannt?

Expertentipp von Laurenz, CTO bei Datasolut: Nehmen Sie den Wunsch der Fachbereiche ernst, eigene Apps zu bauen, und geben Sie ihm einen sicheren Ort, statt es zu verbieten. Jede App, die irgendwo außerhalb der Plattform Daten aus dem Produktivsystem zieht, ist ein mögliches Datenleck. Verbote verlagern das Problem nur in Werkzeuge, die Sie nicht mehr sehen.

Typischer Fehler: Viele möchten sofort mit einer anspruchsvollen App einsteigen, da diese den größten Nutzen verspricht. Scheitern solche Projekte jedoch an Berechtigungen oder Last, ist das Thema intern für Monate abgehakt.

Steuern: Von geregelten Daten zu geregelten Apps

Unity Catalog regelt, wer welche Tabelle sehen darf. Bei einer App kommen weitere Fragen dazu, wodurch hier die meisten Lücken entstehen. Aus diesem Grund hilft es, die vier Ebenen getrennt zu betrachten:

Laut Dokumentation zu App-Berechtigungen ist ein anonymer, öffentlicher Zugriff nicht vorgesehen. Wer die App öffnet, ist somit immer ein angemeldeter Databricks-Nutzer.

Welches Berechtigungsmodell passt zu Ihrer App?

Jede App erhält ein eigenes Dienstkonto und greift damit auf freigegebene Ressourcen zu, unabhängig davon, wer sie gerade nutzt. Alternativ handelt die App über die Nutzer-Autorisierung im Namen der angemeldeten Person, wobei deren Rechte, Zeilenfilter und Spaltenmasken gelten. Diese Variante ist seit 2026 allgemein verfügbar.

Unabhängig vom Modell gelten einige Grundregeln. Persönliche Zugangsschlüssel (Personal Access Tokens) gehören beispielsweise nie in den Code. Alle benötigten Ressourcen wie SQL Warehouses, Modelle oder Secrets, also hinterlegte Zugangsdaten wie Passwörter und API-Schlüssel, werden in der Konfigurationsdatei app.yaml nur über ihren Namen referenziert, statt fest im Code zu stehen. Liest eine App nur, bekommt ihr Dienstkonto auch nur Leserechte. Berechtigungen gehen dabei an Gruppen und nicht an Einzelpersonen.

App Spaces: Leitplanken für viele kleine Apps

Stellen Sie sich eine Werkstatt mit Werkzeugausgabe vor. Wer dort arbeitet, baut frei, aber nur mit den Werkzeugen, die auch im Regal liegen. App Spaces funktionieren ähnlich, weil nur Administratoren einen Space anlegen und dort bestimmen können, welche Ressourcen, Berechtigungen und Anmeldewege gelten. Wer im Space Apps baut, übernimmt diese Einstellungen nur und kann sie nicht selbst ändern.

Auf diese Weise wird ein bekanntes Problem gelöst. Bisher brauchte jemand, der eine App an ein SQL Warehouse anbinden wollte, selbst die nötigen Rechte darauf. Im Space hat der Administrator das einmal für alle erledigt. Apps in einem Space laufen als sogenannte Serverless Micro Apps, die bei Nichtnutzung abschalten und beim nächsten Aufruf in wenigen Sekunden wieder starten.

Darüber hinaus legt der Administrator fest, mit welcher Identität Apps im Space handeln dürfen, zum Beispiel nur mit den Rechten einer bestimmten Gruppe. Jede App erhält außerdem ein eigenes Dienstkonto, über das sie in den Protokollen eindeutig identifiziert werden kann.

Warum Lakehouses die Daten-Architektur der Zukunft sind

In unserem Whitepaper erfahren Sie:

• Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
• Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
• Wie Sie ihr internes Team befähigen selbstständig KI Projekte zu implementieren.

Jetzt herunterladen

Wichtig für Ihre Planung: App Spaces sind laut Databricks in der Beta-Phase und setzen die Vorschaufunktion „Governed agentic app-building“ voraus. Darüber hinaus verhindern sie nicht, dass berechtigte Nutzer außerhalb eines Spaces weiter klassische Apps erstellen.

Externe Werkzeuge bieten inzwischen auch ähnliche Leitplanken. Über die Anbindung von Replit arbeiten Fachanwender nur mit freigegebenen Entwicklungsdaten. Bevor die fertige App in der Databricks-Umgebung veröffentlicht wird, zeigt das Werkzeug, welche Tabellen in Lakebase neu entstehen, und erlaubt eine Vorschau auf einer Kopie der Produktionsdatenbank.

Bauen: Welches Werkzeug zu welchem Team passt

Für den Bau gibt es zwei sehr unterschiedliche Gruppen, von denen beide etwas anderes brauchen.

Fachanwender ohne Programmiererfahrung nutzen den Genie App Builder, der Apps in einem App Space aus einer Beschreibung in natürlicher Sprache erstellt. Die App ist schon während der Entstehung sichtbar und Fehler im Browser findet der Agent selbst. Stand Oktober 2026 befindet er sich allerdings noch in der Beta-Phase.

Entwickler arbeiten lieber mit ihren eigenen Werkzeugen. Für sie stellt Databricks offizielle Agent Skills bereit, die Coding-Agenten beibringen, Databricks richtig zu nutzen. Das Repository unterscheidet dabei stabile und experimentelle Skills, was eine Einstufung im Repository und keinen offiziellen Produktstatus darstellt. Wer mehrere Agenten parallel nutzt, findet in Omnigent eine gemeinsame Oberfläche.

Unter beiden Wegen liegt oft das AppKit, ein TypeScript-Baukasten auf Basis von React und Express. Er bringt bereits Wiederholversuche, Zeitlimits, Zwischenspeicher und Anbindungen an SQL Warehouse, Unity Catalog und Lakebase mit. Einen offiziellen Gesamtstatus über die Verfügbarkeit weist Databricks für das AppKit jedoch nicht eindeutig aus.

Praxistest: Laurenz baut eine App mit dem Genie App Builder

Wie gut funktioniert das für jemanden, der keine Zeile Code schreiben will oder kann? Laurenz hat es mit seiner ersten App im Builder ausprobiert.

Als Grundlage dienten die öffentlich verfügbaren New Yorker Taxifahrten. Sein Briefing legte Ziel, Datenbasis, Kernfunktionen und Design fest. Gewünscht waren Kennzahlen, Zeitverlauf und eine Wochentag-Stunden-Matrix, eine Karte mit den zehn häufigsten Routen, Preisverteilungen und gemeinsame Filter für alle Diagramme.

Der Agent stellte zuerst Rückfragen, etwa ob ein serverloses SQL Warehouse genutzt werden soll und welches Farbschema gewünscht ist. Danach legte er einen nachvollziehbaren Plan an: Abfragen schreiben, Datentypen prüfen, Oberfläche bauen, testen, speichern. Den Code kann man jederzeit einsehen.

Nach ungefähr zehn Minuten lief die erste Version. Beim ersten Start trat ein Fehler auf, den der Agent selbst fand und behob. Die Karte war zunächst schwach, da New York kaum zu erkennen war und es nicht möglich war, zu zoomen. Nach einer zweiten Runde von weiteren zehn Minuten ließ sie sich vergrößern und zeigte beim Überfahren mit der Maus Fahrtenzahl und Durchschnittspreis. Zum Zeitpunkt des Tests war der App Builder noch kostenfrei, die fertige App und das SQL Warehouse werden aber wie gewohnt nach Nutzung abgerechnet.

Bereitstellung: Jede Version ist nachvollziehbar

Apps lassen sich direkt aus Git oder über Declarative Automation Bundles bereitstellen. Für produktive Apps empfehlen wir einen festen Ablauf:

1. Code prüfen, testen und Abhängigkeiten auf feste Versionen setzen
2. In eine Entwicklungsumgebung ausrollen und Grundfunktionen testen
3. Lasttest mit dem erwarteten Nutzungsprofil
4. Freigabe und Ausrollen in die Produktion, festgelegt auf einen bestimmten Git-Stand
5. Rückweg zur letzten freigegebenen Version dokumentieren

Manuelle Änderungen direkt in der Produktion sind der schnellste Weg zu einer App, die niemand mehr nachbauen kann.

Lakebase als Backend: Wann Ihre App eine eigene Datenbank braucht

Viele Apps brauchen keine eigene Datenbank. Wer Kennzahlen anzeigt und filtert, liest mit einem SQL Warehouse direkt aus Unity Catalog. Lakebase, die verwaltete Postgres-Datenbank von Databricks, wird erst interessant, wenn die App selbst etwas festhält.

Ein gutes Muster zeigt die Korrektur von Datenqualität. Die Prüfung von Millionen Zeilen läuft im Lakehouse, denn dafür ist Spark gebaut. Fehlerhafte Datensätze werden hier nicht verworfen, sondern in Lakebase übergeben. Dort bearbeiten Fachleute sie über eine App, in der mehrere Personen gleichzeitig arbeiten können.

Dabei ist für jeden Datensatz festgehalten, wer was bearbeitet und geändert hat. Erst nach dem Absenden der Korrekturen fließen sie zurück ins Lakehouse und durchlaufen dieselben Prüfregeln noch einmal. So entscheidet am Ende die Prüfung und nicht der Mensch allein, was als vertrauenswürdig gilt.

Technisch bindet man Lakebase als Ressource an die App, woraufhin Databricks eine Postgres-Rolle für das Dienstkonto der App anlegt. Die Zugangsschlüssel laufen nach einer Stunde ab und werden automatisch erneuert, was Ihre App beim Verbindungsaufbau berücksichtigen muss. Lakebase Autoscaling ist auf AWS und Azure allgemein verfügbar, die ältere Variante Lakebase Provisioned läuft dagegen als Public Preview. Beide Varianten sollten Sie in der Planung sauber voneinander trennen.

Wie viel Lakebase in der Praxis bewirken kann, zeigt unser Projekt Databricks Lakebase in der Versicherungsbranche: von 90 Sekunden auf unter 1 Sekunde.

Skalieren und überwachen: Erst verstehen, dann vergrößern

Wird eine App langsam, ist der erste Reflex, eine größere Instanz zu buchen. Das hilft allerdings oft nicht. Eine App hängt an mehreren Diensten, und der Engpass kann überall liegen. Typisch sind eine langsame Abfrage im SQL Warehouse, eine zu kleine Lakebase oder der Browser der Nutzer. In all diesen Fällen bringt mehr Rechenleistung für die App nichts. Gehen Sie deshalb in vier Schritten vor:

Schritt 1: Verstehen, was die App tut

Klären Sie mit den Nutzern, wo es hakt und was die App leisten soll. Werten Sie Protokolle aus, um die betroffene Schicht zu finden. Erst wenn Abfragen, Datenbank und Oberfläche unauffällig sind, liegt das Problem bei der App selbst.

Schritt 2: Lasttest mit echtem Nutzungsmuster

Testen Sie zuerst die einzelnen Bausteine, etwa ob das SQL Warehouse die gewünschte Zahl gleichzeitiger Abfragen schafft. Danach testen Sie die App so, wie auch Nutzer sie verwenden würden, also vom Klick in der Oberfläche, über die Abfrage bis zur angezeigten Antwort.

Für Lasttests gibt es erprobte Werkzeuge wie Locust oder k6. Wichtig ist es, folgendes Muster zu beachten: Sollten Sie am Montagmorgen einen Ansturm erwarten, simulieren Sie diesen Ansturm vorher. Eine langsam steigende Testlast, die gut aussieht, erweckt den falschen Eindruck von Sicherheit.

Schritt 3: Gezielt skalieren

Vertikal heißt: größere Instanz. Die Dokumentation zur App-Rechenleistung nennt zwei Größen. Medium hat bis zu 2 vCPUs und 6 GB Arbeitsspeicher für 0,5 DBU pro Stunde, Large bis zu 4 vCPUs und 12 GB für 1 DBU pro Stunde. Databricks selbst empfiehlt, zuerst mit Medium zu starten und erst bei nachweisbaren Leistungsproblemen auf Large zu wechseln.

Horizontal heißt: mehrere Instanzen hinter einer Adresse. Die horizontale Skalierung ist eine Beta, standardmäßig sind ein bis fünf Instanzen einstellbar, und die Kosten steigen mit jeder Instanz linear an. Nutzer bleiben dabei möglichst derselben Instanz zugeordnet. Die Zahl der Instanzen legen Sie selbst fest. Gleichzeitig ist ein automatisches Mitwachsen der Last ist nicht dokumentiert.

Für Streamlit- und Gradio-Apps würden wir keine größere Instanz buchen. Diese Frameworks arbeiten weitgehend auf einem einzigen Prozessorkern, wobei zusätzliche Kerne ungenutzt bleiben und dabei trotzdem Kosten verursachen. Hier ist die horizontale Skalierung der sinnvolle Weg.

Schritt 4: Laufend überwachen

Apps schreiben Protokolle über die Standardausgabe. Ohne weitere Speicherung können diese beim Herunterfahren verloren gehen. Mit der App-Telemetrie auf Basis von OpenTelemetry landen Protokolle, Ablaufspuren und Messwerte in Tabellen in Unity Catalog.

Systemprotokolle werden automatisch erfasst und müssen durch eigene Messwerte ergänzt werden. Beobachten Sie mindestens Antwortzeiten (P95 und P99), Fehlerquote sowie Prozessor- und Speicherauslastung. Den Status der Telemetrie weist Databricks nicht einheitlich aus, rechnen Sie daher mit einer Vorschau- oder Betafunktion.

Was kosten Databricks Apps im laufenden Betrieb?

Abgerechnet wird die Zeit, in der die App läuft, gemessen in DBU. Die Rechnung ist einfach:

Laufzeit × DBU pro Instanzstunde × Anzahl der Instanzen × DBU-Preis

Den gültigen Preis für Ihre Cloud und Region finden Sie auf der offiziellen Preisseite.

Ein Beispiel: Eine App der Größe Medium, die rund um die Uhr läuft, verbraucht in einem Monat mit rund 730 Stunden etwa 365 DBU. Die gleiche App in Large verbraucht rund 730 DPU und mit zwei Instanzen das Doppelte. Klassische Apps fahren nicht von selbst auf null herunter. Eine App, die nur einmal im Monat genutzt wird, kostet daher trotzdem den ganzen Monat, sofern sie nicht gestoppt wird. Automatisches Abschalten bei Nichtnutzung gibt es bisher nur für die Micro Apps in App Spaces.

Zur App kommen zusätzlich Folgekosten hinzu, die oft größer als die App selbst sind. Dazu gehören Abfragen im SQL Warehouse, Lakebase, Model Serving, Jobs und die gespeicherte Telemetrie. Für die Kostenkontrolle haben sich diese Regeln bewährt:

• Jede App mit Kostenstelle, Umgebung und verantwortlichem Team kennzeichnen
• Mit Medium starten und erst nach einem Lasttest vergrößern
• Entwicklungs- und Demo-Apps regelmäßig prüfen und stoppen
• Kosten für App, SQL Warehouse, Lakebase und Modelle getrennt auswerten

Wie Sie diese Kosten plattformweit steuern, beschreiben wir im Artikel FinOps auf Databricks.

Apps im Databricks Marketplace sind erst der zweite Schritt

Seit Juni 2026 lassen sich Apps als Public Preview über den Databricks Marketplace verteilen. Als Nutzer installieren Sie fertige Fach- oder Branchenanwendungen von Drittanbietern, die dann in Ihrer eigenen Umgebung, auf Ihrer Rechenleistung und mit den Ressourcen, die Sie bei der Installation freigeben, laufen. Vor der Installation sehen Administratoren, welche Berechtigungen, Ressourcen und externen Adressen die App benötigt. Genau diese Liste sollten Sie wie bei jeder anderen Software prüfen.

Als Anbieter können Sie eine bewährte App als Produkt für Kunden oder Partner veröffentlichen, ohne den Quellcode offenzulegen. Das lohnt sich nach unserer Einschätzung jedoch erst, wenn die App intern stabil läuft. Wer mit dem Marketplace beginnt, hat die Fragen aus den Abschnitten zu Steuerung und Betrieb nur auf später verschoben.

Welcher Weg passt zu Ihrer Ausgangslage?

Stand heute entwickelt Databricks diesen Bereich in hohem Tempo. Viele der beschriebenen Funktionen sind noch in der Beta- oder Vorschau-Phase und können sich bis zur allgemeinen Verfügbarkeit ändern.

Fazit: Apps auf Databricks lohnen sich, wenn Sie sie wie Produkte behandeln

Apps auf Databricks schließen die Lücke zwischen dem Lakehouse und dem Arbeitsplatz der Fachbereiche an einem Ort, an dem Ihre Regeln für die Daten bereits gelten. Der schwierige Teil ist selten das Bauen, denn ein Agent liefert eine erste Version heute in Minuten. Entscheidend ist, unter welcher Identität die App auf Daten zugreift, ob sie echter Last standhält und wer sie in einem Jahr noch betreut.

Unsere Empfehlung ist es, mit einer lesenden App für eine Abteilung in der Größe Medium anzufangen. Legen Sie vorher fest, mit welchem Berechtigungsmodell sie arbeitet und wer fachlich und technisch verantwortlich ist. Läuft sie stabil, können schreibende Funktionen mit Lakebase dazukommen und danach weitere Abteilungen über App Spaces. Den Genie App Builder können Sie schon heute ausprobieren, wegen des Beta-Status aber noch nicht zur Grundlage geschäftskritischer Anwendungen machen.

Vinzent Wuttke

Geschäftsführer

Ihr nächster Schritt mit uns!

Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.

Im kostenlosen Erstgespräch klären wir:

• Welche Rollen und Teams von welchem Paket am meisten profitieren
• Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
• Wie ein realistischer Zeitplan und die nächsten Schritte aussehen

Erstgespräch vereinbaren

FAQ: Die häufigsten Fragen zu Apps auf Databricks