Über uns

Wir haben beides gebaut – und wissen deshalb, was wir ersetzen

Über fünfzehn Jahre Arbeit an Data, Analytics und KI – bei IBM und bei mindsquare, im Konzern und im Mittelstand. lavalake ist die Konsequenz daraus: die Flexibilität einer Cloud-Datenplattform, auf Ihrer eigenen Hardware.

Warum wir das bauen

Sie brauchen eine Datenplattform, die moderne Werkzeuge mitbringt. Die guten gibt es fast nur als Dienst – und damit erben Sie zwei Probleme, die miteinander nichts zu tun haben: eine Rechnung, die mit Ihrem Erfolg wächst, und Daten, die Ihr Haus verlassen.

Die Rechnung trifft Sie zuerst. Wer nach Credits abgerechnet wird, zahlt für Neugier: jede zusätzliche Auswertung, jedes Dashboard, das ein Fachbereich oft öffnet, jeder Test einer Idee steht auf der nächsten Abrechnung. Irgendwann drosseln Sie Datenarbeit, um Kosten zu drosseln – das Gegenteil von dem, wofür Sie die Plattform angeschafft haben.

Bei der Kontrolle geht es um mehr als den Standort. Wem gehört das Tabellenformat, wenn Sie wechseln wollen? Wer sieht welche Zeile, wenn ein KI-Agent fragt? Kann im Protokoll nachträglich etwas verschwinden? Wer Patientendaten, Akten, Konstruktions- oder Produktionsdaten verantwortet, entscheidet an diesen Fragen über eine Freigabe – nicht am Funktionsumfang.

Und Sie werden die KI-Frage beantworten müssen, wahrscheinlich früher als geplant. Sie lautet nicht, ob ein Agent Ihre Tabellen abfragen kann, sondern ob er es darf und wer hinterher nachvollzieht, was er gesehen hat. Deshalb ist hier die Rechtekette zuerst entstanden und der Agent danach: Er bekommt kein eigenes Konto, sondern die Rechte des Anmeldenden, jede Anweisung wird eingestuft, protokolliert und bei Eingriffen zur Bestätigung vorgelegt. Ein Assistent, der später als Funktion nachgerüstet wird, bekommt diese Kette nicht mehr.

Für all das gibt es kein Naturgesetz. Getrenntes Storage und Compute, ein offenes Tabellenformat, eine Semantikschicht und ein MCP-Server laufen in Ihrem Rechenzentrum. Was fehlte, war ein Produkt, das diese Schichten zusammen ausliefert – mit einem Rechtemodell statt sechs, zu einem Preis, der nicht davon abhängt, wie neugierig Ihre Analysten sind.

Wir kommen dabei nicht von außen. Data-Warehouse-Architektur bei IBM, Betrieb eines Cloud Data Warehouses auf Snowflake-Basis, zwölf Jahre Enterprise-Systeme und KI-Projekte bei mindsquare: wir kennen die Plattformen, die Sie ersetzen wollen, und die Häuser, in denen sie nicht laufen dürfen.

Vier Entscheidungen, die das Produkt erklären

Wir haben keine Query-Engine gebaut

Es läuft Trino. Eine eigene Engine wäre die aufwendigste und am wenigsten nützliche Eigenleistung gewesen – entscheidend ist nicht, wer den Scan schreibt, sondern dass jede Anweisung unter dem eingetauschten Token des Anmeldenden läuft. Dieselbe Überlegung bei Iceberg und Keycloak: offene Bausteine, die es besser können, dafür unsere Arbeit an der Kette dazwischen.

Ein Dokument wird eine Tabelle

PDFs landen nicht in einem zweiten Inhaltsspeicher mit eigener Zugriffskontrolle, sondern als Abschnitte in einer Iceberg-Tabelle. Der Umweg klingt umständlich und ist der Grund, warum Rechte, Audit und Herkunft für Dokumente ohne eine einzige zusätzliche Regel gelten.

Der Suchindex hält keine Inhalte

Der Vektorindex merkt sich, wo etwas steht, nicht was dort steht. Treffer werden unter dem Token des Suchenden aus Trino nachgeladen. Ein Index mit Inhalten wäre schneller – und ein zweiter Datenbestand, dessen Rechte irgendwann von den echten abweichen.

Die BI-Ausleitung ist ab Werk aus

Der Datenfeed nach draußen antwortet mit 403, bis ein Administrator ihn bewusst einschaltet. Das kostet einen Klick und beantwortet die Frage, die bei einer Freigabe wirklich gestellt wird: welche Daten dürfen dieses Haus überhaupt verlassen.

Woher das kommt

Zwei Wege, die 2024 dieselbe Wand treffen – einmal von der Warehouse-Seite, einmal von der KI-Seite.

Automotive, ab 2016
Data-Warehouse-Arbeit bei IBM im Bereich Analytics, Data und AI. Die Erfahrung, wie ein Warehouse aussieht, das Produktionsdaten trägt.
ML im Betrieb, ab 2016
Auf der anderen Seite maschinelles Lernen im laufenden Betrieb: Ticket-Klassifikation, Vorhersage von Incident-Häufungen, Automatisierung wiederkehrender Aufgaben – Jahre bevor generative Modelle Aufmerksamkeit bekamen.
Verantwortung, ab 2019
Fünfzehn Mitarbeitende, fünfundzwanzig produktive Anwendungen, ITIL-Betrieb mit zugesagter Servicequalität. Dort lernt man, was „läuft in Produktion“ von „läuft im Labor“ unterscheidet. Ab 2021 dazu Forschung an der FernUniversität in Hagen zu autonomen Multi-Agent-Systemen.
Snowflake, 2024
Betrieb eines Cloud Data Warehouses auf Snowflake-Basis nach Data Vault 2.0 bei der SUND Group. Danach kennt man beide Seiten: was so eine Plattform kann, und was sie kostet.
Selbst gehostet, 2024
KI-Agenten für Kunden, die ihre Daten nicht in eine SaaS-Plattform legen – zwei eigene Plattformen für Voice-, Chat- und Avatar-Bots und für autonome Agenten, produktiv auf eigener Infrastruktur. Dieselbe Wand, nur von der KI-Seite: die guten Werkzeuge gibt es nur als Dienst.
Kostenfrage, 2025
In Kundenprojekten läuft immer dasselbe Muster auf: die Rechnung für das Cloud-Data-Warehouse wächst schneller als der Nutzen, und niemand kann vorher sagen, was eine Auswertung kosten wird. Damit ist die Lücke benannt – sie ist nicht nur eine Frage der Datenhoheit, sondern eine der Kalkulierbarkeit.
lavalake, 2026
Lakehouse, Governance, Suche und Agent als ein Produkt, mit einem Rechtemodell statt sechs – auf der Hardware des Kunden.

Wer dahintersteht

lavalake wird von Nils Gregersen und Daniel Alisch gebaut. Beide schreiben im Blog über die Themen, an denen sie arbeiten.

Daniel Alisch

Co-Founder lavalake

Daniel ist Senior AI Consultant bei der mindsquare AG, wo er seit 2014 durch alle Stufen gegangen ist: vom Junior Consultant über die Verantwortung als Application Owner bis zum Managing Consultant mit fachlicher und disziplinarischer Führung für fünfzehn Mitarbeitende und fünfundzwanzig produktive Anwendungen.

Maschinelles Lernen hat er im Betrieb eingesetzt, lange vor dem Aufmerksamkeitsschub um generative Modelle: Ticket-Klassifikation, Vorhersage von Incident-Häufungen, Automatisierung wiederkehrender Betriebsprozesse. Diese Sicht – erst der Betrieb, dann das Modell – prägt die KI-Schicht von lavalake.

Heute baut er Multi-Agent-Systeme und RAG-Pipelines für Enterprise-Umgebungen, mit LangGraph, MCP, Qdrant und PostgreSQL. Zwei eigene Plattformen laufen produktiv: eine für Voice-, Chat- und Avatar-Bots auf DSGVO-konformer eigener Infrastruktur, und eine für autonome Agenten in isolierten Containern mit Kostenzuordnung je Aufgabe – letztere quelloffen.

Aus zwölf Jahren in SAP- und Non-SAP-Landschaften kommt der Teil, der Datenprojekte in der Praxis aufhält: Schnittstellen. Deshalb kann lavalake Quellen über registrierte MCP-Server anbinden – SAP über SAP-MCP – und nicht nur, was einen JDBC-Treiber mitbringt.

Der Anlass war derselbe, der hinter lavalake steht: ein Kunde wollte keine Daten in einer SaaS-Plattform, ein anderer brauchte eine selbst gehostete Lösung. Parallel forscht Daniel seit 2021 an der FernUniversität in Hagen zu autonomen Multi-Agent-Systemen.

Wirtschaftsinformatik · B.Sc. HWR Berlin, M.Sc. FernUniversität in Hagen
mindsquare AG · Application Owner, ITIL-Betrieb mit ML
mindsquare AG · Managing Consultant, 15 Mitarbeitende, 25 Anwendungen
SAP · zwölf Jahre in SAP- und Non-SAP-Landschaften, Basis und Schnittstellen
FernUniversität in Hagen · Forschung zu Multi-Agent-Systemen, seit 2021
mindsquare AG · Senior AI Consultant, seit 2024

Nils Gregersen

Co-Founder lavalake

Nils hat bei der Hamburger Hochbahn angefangen – Ausbildung, dann stellvertretende und schließlich eigene Leitung eines Teams von über dreißig Mitarbeitern. Wirtschaftsinformatik hat er dabei nebenberuflich an der Hochschule Wismar studiert, Bachelor und Master, von 2012 bis 2019 – also parallel zur Teamleitung und später parallel zu den ersten Jahren bei IBM.

Prägend für lavalake sind die fünf Jahre danach bei IBM, in Analytics, Data und AI: zuerst im Watson IoT Center an kognitiven und analytischen Projekten der Automobilindustrie, dann an der Datenplattform, auf der Modelle für autonomes Fahren trainiert werden. Dort lernt man, was eine Datenplattform aushalten muss, wenn Produktions- und Fahrzeugdaten zusammenkommen.

Bei SUND verantwortet er seit 2024 als IT-Projekt & KI Innovation Manager unter anderem ein Cloud Data Warehouse auf Snowflake-Basis, modelliert nach Data Vault 2.0. Er kennt die Stärken einer solchen Plattform also aus dem laufenden Betrieb – und die Rechnung, die Credit-Abrechnung und die Bindung an ein geschlossenes Tabellenformat aus derselben Erfahrung.

Dazu kommt die unternehmerische Seite: Paycer als Co-Founder und CEO, danach eine Station in Singapur als COO des Gold-Tokens CACHE und bei Silver Bullion, und seit 2026 Spargold – Umgebungen, in denen Nachvollziehbarkeit keine Kür ist.

Hamburger Hochbahn · von der Ausbildung zur Teamleitung, über 30 Mitarbeiter, 2009–2016
Wirtschaftsinformatik · B.Sc. und M.Sc. Hochschule Wismar, nebenberuflich, 2012–2019
IBM · fünf Jahre in Analytics, Data und AI, ab 2016
Paycer · Co-Founder und CEO, 2021–2023
CACHE · COO, Station in Singapur
SUND · IT-Projekt & KI Innovation Manager, seit 2024
Spargold · Co-Founder und Geschäftsführer, seit 2026

Reden wir über Ihren Fall

In dreißig Minuten sehen Sie Ihre Architektur, eine Kostenrechnung mit offengelegten Annahmen und eine ehrliche Einschätzung, ob sich der Wechsel für Sie lohnt.

Demo anfragen