Im Juli waren wir am Databricks Lakebase Hackathon in Zürich dabei. Was die Teams in kurzer Zeit auf die Beine stellten, war beeindruckend: Chat-App für Gesundheitsdaten, Tools für Risikomanagement, Apps für Marketingkampagnen sowie Lösungen für Handel und Prognosen im Energiesektor.
Lakebase ist die vollständig verwaltete, serverlose PostgreSQL-Datenbank-Lösung von Databricks für transaktionale Workloads (OLTP). Sie ist für Anwendungen gebaut, welche Lese- und Schreibzugriffe mit niedriger Latenz benötigen und dabei direkt auf bestehende Lakehouse-Daten zugreifen.
Databricks hatte ELCA eingeladen, die Teams während des ganzen Events bei Plattformfragen zu unterstützen. Wir halfen dort, wo es konkret wurde: Lakebase-Verbindungen einrichten, Daten synchronisieren und gemeinsam überlegen, wie sich einzelne Funktionen im jeweiligen Use Case umsetzen lassen.
Damit die Teams schnell starten konnten, haben wir vor der Veranstaltung ausserdem ein Lakebase-Quickstart-Repository vorbereitet. Mehrere Teams nutzten es als Ausgangspunkt, was den Einrichtungsaufwand zusätzlich reduzierte und ihnen einen schnelleren Einstieg in ihre jeweiligen Use Cases ermöglichte. Ab da ging es in unseren Gesprächen kaum noch ums Setup, sondern um die Projekte selbst: um Datenflüsse und ganz konkrete Anwendungsfragen.
Rückblickend sind uns drei Punkte besonders aufgefallen.
1. Die Infrastruktur stand vor dem zweiten Kaffee
An einem Hackathon fällt jede Hürde bei der Infrastruktur doppelt ins Gewicht. Wer zwei, drei Stunden mit Provisionierung, Zugangsdaten und Umgebung verliert, hat schnell den halben Tag verspielt.
Lakebase hat diesen Ausgangspunkt verändert. Die Infrastruktur stand automatisch und innert kürzester Zeit bereit. Das Branching in Lakebase stellt dank Copy-on-Write-Speicher in Sekunden isolierte, beschreibbare Kopien bereit. Zudem können inaktive Ressourcen auf null herunterskalieren und bei Bedarf innerhalb weniger hundert Millisekunden automatisch wieder starten.
Für einen Hackathon ist genau diese Geschwindigkeit entscheidend. Entwickler können auf isolierten Branches arbeiten, Änderungen ausprobieren, ohne die Hauptdatenbank anzufassen, erfolglose Versuche verwerfen und weitermachen.
Zusammen mit unserem Quickstart und dem gewohnten PostgreSQL-Tooling war die Einrichtung der Datenbank schnell kein Thema mehr. Beim zweiten Kaffee arbeiteten die Teams bereits fokussiert an ihren Use Cases statt an der Infrastruktur.
2. Die wertvollste Pipeline ist die, die man weder bauen noch warten muss
Eines der interessantesten Projekte war eine Chat-App für persönliche Gesundheitsdaten. Die Anwendung kombinierte Daten aus Unity Catalog und Lakebase, sodass Nutzende Fragen zu ihren eigenen Daten stellen konnten. Anschliessend erweiterte das Team sie mit Agent Bricks und setzte eine RAG-basierte Prüfschicht ein, um die generierten Antworten zu validieren.
Das Projekt zeigt schön, wo Lakebase seine Stärken ausspielt. Viele Anwendungen brauchen Daten, die längst im Lakehouse liegen und dort sauber verwaltet werden: Kundeninformationen, Kennzahlen, Modellergebnisse oder Referenzdaten. Damit diese Daten schnell genug für eine Anwendung bereitstehen, braucht es klassischerweise eine zusätzliche operative Datenbank und eine Pipeline, die alles aktuell hält.
Mit Lakebase Synced Tables entfällt dieser Umweg. Daten aus Unity Catalog stehen über PostgreSQL direkt mit niedriger Latenz zur Verfügung. Es gibt keine selbst gebaute Sync-Pipeline und somit auch nichts zu warten. So blieben die Teams nicht bei Standard-Infrastruktur und einfachen Eingabemasken stehen, sondern konnten ihre Zeit in spannende Funktionen investieren.

3. Vom Lakehouse direkt zur Anwendung
Verfügbare, zentral verwaltete Daten sind erst die halbe Miete. Die andere Hälfte besteht darin, diese Daten in Anwendungen zu verwandeln, die Menschen tatsächlich nutzen können.
Genau diesen Schritt haben die Teams am Hackathon umgesetzt, zum Beispiel:
- Eine Anwendung zur Verwaltung von Risikoregeln machte aus Daten einen operativen Workflow.
- Ein Tool zur Umverteilung von Mitarbeitenden unterstützte den Lagerbetrieb.
- Eine weitere Anwendung verband Kennzahlen und Lineage mit einem Feedback-Workflow auf Basis von Lakebase.
Anwendungen müssen Eingaben erfassen, Zustände speichern und Aktionen auslösen. Dafür liefert Lakebase eine transaktionale Datenbank direkt neben dem Lakehouse. So lassen sich operative Funktionen nah an den bereits vorhandenen Daten entwickeln, statt analytische Daten in einen separaten Applikationsstack zu exportieren.
Für uns war das eine der wichtigsten Beobachtungen des Tages. Das Lakehouse war nicht mehr nur ein Ort für Analysen, sondern die Grundlage für Anwendungen, die rund um diese Daten entstehen.
Was Ihnen weder Plattform noch KI abnimmt
Lakebase übernimmt einen grossen Teil der Betriebsarbeit, und auch KI-gestützte Entwicklung beschleunigt die Umsetzung zusätzlich. Ein durchdachtes Datenmodell braucht es trotzdem. Es bleibt PostgreSQL. Und es bleibt Engineering.
Primärschlüssel, Indizes und Zugriffsmuster spielen weiterhin eine Rolle. Ebenso die Entscheidung, was in eine operative Datenbank gehört, was analytisch bleiben soll und wie Daten zwischen beiden Welten fliessen.
Das zeigte sich während des ganzen Hackathons. Die Teams kamen schnell voran, und sobald Fragen zu Architektur oder Best Practices auftauchten, wandten sie sich an uns. Genau dafür waren wir da, und genau hier schafft ELCA Mehrwert: Wir verbinden Plattformexpertise und Engineering-Erfahrung mit KI-gestützter Entwicklung, damit Geschwindigkeit zur richtigen Lösung führt und nicht bloss zu einer schnelleren Umsetzung.
Passt Lakebase in Ihre Architektur?
Lassen Sie uns darüber sprechen. Wir schauen uns gemeinsam Ihre operativen und analytischen Workloads an und zeigen, wo Lakebase Ihre Architektur vereinfachen kann.
