BI ohne Data Lake

Die meisten BI-Projekte in Startups beginnen zu fruh und zu grob.

Ein Founder stellt eine einfache Frage: "Kommen Nutzer aus diesem Kanal nach ihrem ersten Run wieder?" Die Antwort sollte eine Abfrage sein. Stattdessen wird daraus oft ein Plattformprojekt: alle Quellen verbinden, ein Warehouse aufbauen, Events definieren, Identitaten bereinigen, Dashboards verdrahten und warten.

Diese Arbeit wird irgendwann wichtig. Fur ein kleines Team ist sie am Anfang aber oft der falsche erste Schritt. Die Produktdatenbank weiss bereits das meiste, was ein Founder wissen muss. Sie weiss, wer sich registriert hat, wer etwas ausgefuhrt hat, was genutzt wurde, was es gekostet hat, was fehlgeschlagen ist und ob jemand zuruckgekommen ist.

Das eigentliche Problem ist nicht, wo die Wahrheit liegt. Das Problem ist, wie ein Agent diese Wahrheit analysieren kann, ohne die rohe Produktionsdatenbank offenzulegen.

Genau dieses Muster nutzen wir bei VM0: ein maskierter, read-only Neon Branch, der unseren Agents genug Wahrheit fur BI gibt, ohne ihnen Daten zu zeigen, die sie nie sehen sollten.

Das Founder-Problem: Die Fragen kommen vor dem Data-Team

Fruhes Wachstum scheitert selten daran, dass es keine Fragen gibt. Es scheitert daran, dass niemand Zeit hat.

Jeden Tag will das Founder-Team wissen:

• Wurde der Traffic von gestern zu echten Nutzern?
• Welche Signup-Kanale bringen Menschen, die wirklich etwas ausfuhren?
• Kommen First-Run-Nutzer nach 7 oder 30 Tagen zuruck?
• Welche zahlenden Accounts werden still?
• Welche Model Route treibt Kosten?
• Verbrennen Trial-Abuser Compute, bevor sie konvertieren?
• Ist die Produktgesundheit seit gestern besser oder schlechter geworden?

Nichts davon ist exotisch. Das ist der operative Rhythmus eines Startups.

Aber mit dem klassischen BI-Playbook erzeugen diese Fragen viel Overhead. Meist beginnt man damit, Daten aus der Produktdatenbank in ein anderes System zu verschieben. Dann werden sie normalisiert, Metriken definiert, Beziehungen neu aufgebaut und Dashboards erstellt. Das Team bekommt einen saubereren Analytics-Stack, aber der Founder wartet Tage oder Wochen auf eine Antwort, die als SQL-Abfrage hatte beginnen konnen.

Fur ein kleines Startup kann diese Reihenfolge verkehrt sein. Man braucht keine vollstandige Datenplattform, um die ersten 20 operativen Fragen zu beantworten. Man braucht einen sicheren Weg, die Quelle der Wahrheit abzufragen, die schon existiert.

Die Datenbank ist bereits die Source of Truth

Bei VM0 enthalt die Produktdatenbank die Fakten, die fur viele Founder-Entscheidungen wichtig sind:

• Organisationen und Nutzer
• Signup- und Subscription-Status
• Agent Runs und Schedules
• Credit-Verbrauch und Usage Events
• Ausgewahlte Modelle und Provider Routes
• Connector-Status
• Fehlerstatus und Zeitstempel

Diese Beziehungen existieren bereits. Sie sind frischer als jedes nachgelagerte Dashboard und spiegeln wider, wie das Produkt wirklich funktioniert.

Das ist wichtig, weil viele fruhe BI-Fragen relational sind. Ein Founder will nicht nur Page Views oder Run Counts sehen. Er will Verhalten uber das System hinweg verbinden:

Von den Nutzern, die sich uber diesen Kanal registriert haben: Wie viele haben am ersten Tag etwas ausgefuhrt, und wie viele kamen nach ihrem ersten Run zuruck?

Oder:

Welche zahlenden Organisationen hatten in den letzten 7 Tagen keinen Run, obwohl sie vorher aktiv wirkten?

Oder:

Wie viel Compute haben neue Trial-Accounts in ihren ersten 6 Stunden verbrannt, vor und nach der Anderung unserer Abuse Patrol?

Diese Fragen liegen naturlich in der Produktdatenbank. Sie werden deutlich schwerer, wenn jede Antwort damit beginnt, Daten erst in eine separate Plattform zu bewegen.

Der unsichere Shortcut ist roher Produktionszugriff

Der verlockende Shortcut ist offensichtlich: den Agent einfach die Produktion abfragen lassen.

Das ist nicht akzeptabel.

Eine Produktionsdatenbank kann das sensibelste Material des Unternehmens enthalten: E-Mail-Adressen, Prompts, Chat-Inhalte, Credentials, verschlusselten Provider State, Logs, Fehlermeldungen, API Keys und interne operative Aufzeichnungen. Selbst wenn ein Agent vorsichtig ist, entsteht ein Grenzproblem. Der Agent sieht zu viel. Ein Fehler in einer Abfrage, einem Report oder einem Screenshot kann Informationen offenlegen, die nie geteilt werden sollten.

Schreibzugriff ist noch schlimmer. BI sollte Produktion nicht verandern konnen. Ein Analyst, menschlich oder agentisch, sollte nie nur einen schlechten Befehl davon entfernt sein, Nutzerdaten zu mutieren.

Die Frage ist also nicht, ob Agents SQL schreiben konnen. Das konnen sie. Die Frage ist, ob man ihnen genug Wahrheit geben kann, damit sie nutzlich sind, wahrend Privacy und Safety harte Grenzen bleiben.

Fur uns sind diese Grenzen der Ausgangspunkt:

• Agents sollten keine rohen Prompts sehen.
• Agents sollten keine rohen E-Mails sehen.
• Agents sollten keine Credentials oder Secrets sehen.
• Agents sollten keine sensiblen Freitext-Logs sehen.
• Agents sollten keinen Schreibzugriff auf die BI-Quelle haben.
• Das Founder-Team sollte trotzdem schnell operative Fragen stellen konnen.

Das war die Form des Systems, das wir brauchten.

Der sichere Mittelweg: eine maskierte Read-only-Datenbank

Neon macht ein nutzliches Muster moglich, weil Branches leichte, isolierte Kopien einer Postgres-Datenbank sind. Man kann einen produktionsahnlichen Branch erstellen, ihn transformieren und diesen Branch statt der Produktion selbst freigeben.

Bei VM0 nennen wir das MaskDB.

Der Ablauf ist einfach:

1. Vom Production Parent Branch in Neon starten.
2. Regelmassig einen frischen Branch erstellen.
3. PostgreSQL Anonymizer und VM0-spezifische Masking Helpers installieren.
4. Security Labels fur sensible Spalten anwenden.
5. Statische Anonymisierung auf dem Branch ausfuhren.
6. Finale Custom Masks fur Spezialfelder anwenden.
7. Eine masked_readonly Rolle mit SELECT-Zugriff erstellen.
8. Agents diese Rolle abfragen lassen, nicht die Produktion.

Der wichtige Punkt ist, dass das Masking statisch ist. Sensible Werte werden auf dem maskierten Branch umgeschrieben, bevor der Agent verbindet. Das ist anders, als jeder nachgelagerten Abfrage beizubringen, was sie nicht auswahlen darf. Der Branch selbst ist die Grenze.

In unserer MaskDB werden Credentials und Secrets redigiert. E-Mails und Telefonnummern werden teilweise maskiert. Nutzerinhalte wie Prompts, Chat-Nachrichten, Schedule Prompts und Agent Outputs werden entfernt. Fehlertexte werden auf eine Klasse reduziert, statt volle Stacks oder Nachrichten offenzulegen. Tabellen, die niemals in Analysen auftauchen sollten, konnen komplett entfernt werden.

Gleichzeitig bleiben opake IDs wie org_id, user_id und clerk_user_id joinbar. Genau das macht BI moglich. Der Agent muss keine E-Mail-Adresse oder Prompt-Texte kennen. Er muss wissen, dass dieselbe Organisation sich registriert, etwas ausgefuhrt, Credits verbraucht, abonniert, pausiert oder spater zuruckgekehrt ist.

Das ist der Kern: menschlich lesbares und sensibles Material maskieren, aber das relationale Ruckgrat erhalten.

Was Agents tun konnen, sobald diese Grenze existiert

Sobald die maskierte Read-only-Datenbank existiert, wird der Agent sehr schnell nutzlich.

Er kann Fragen direkt gegen Produktdaten stellen:

• 7-Tage- und 30-Tage-Retention
• Aktivierung von Registrierung bis First Run
• First-Run-basierte Retention
• Dormante zahlende Organisationen
• Subscription State und Churn Watch
• Modellnutzung nach ausgewahltem Modell
• Built-in vs User-Provider Routes
• Trial Compute Consumption
• Kosten pro Run nach Modell
• Failure Rate und Completion Rate nach Cohort

Er kann diese Datenbankwahrheit auch mit den Systemen darum herum verbinden.

Unser Morning Brief zieht aus Plausible, Axiom, Sentry, Google Ads, GitHub und weiteren operativen Quellen. Die Datenbank zeigt, was Nutzer und Organisationen getan haben. Plausible zeigt, was auf der Website passiert ist. PostHog kann Produkt-Event-Kontext liefern. Axiom zeigt Logs und Request Paths. Sentry erfasst Fehler. Stripe und Clerk erklaren Billing und Identity. GitHub zeigt Engineering Throughput.

Es geht nicht darum, jedes Tool durch SQL zu ersetzen. Es geht darum, dass der Agent die Fakten verbindet, die Founder wirklich interessieren.

Zum Beispiel:

Paid Google brachte gestern mehr Traffic als Organic. Haben diese Nutzer wirklich ihren First Run erreicht, oder sind sie oben im Funnel stecken geblieben?

Oder:

Wir haben die Trial-Abuse Patrol geandert. Verbrennen neue Trial-Accounts in ihren ersten Stunden jetzt weniger Compute?

Oder:

Diese Model Route ist pro Run gunstiger. Zeigt sich das in echter historischer Chat-Nutzung, oder nur in der Preistheorie?

Das sind keine Dashboard-Fragen. Das sind operative Fragen. Sie andern sich von Woche zu Woche, manchmal von Tag zu Tag. Ein Agent mit sicherem Datenbankzugriff kann sie beantworten, ohne dass Engineering jedes Mal eine neue View baut.

Ein echtes Beispiel: Retention und externe Nutzer-Gesundheit

Eine unserer taglichen internen Analysen betrachtet die Gesundheit externer Nutzer uber die letzten 24 Stunden.

Der Report startet mit MaskDB und wendet dann ein striktes Exclusion Set an. Interne VM0-Organisationen werden entfernt. In Clerk gebannte oder gesperrte Spam-Organisationen werden entfernt. Dasselbe Exclusion Set gilt fur jede Metrik, einschliesslich Registrierungszahlen und Retention Cohorts, damit Nenner nachvollziehbar bleiben.

Daraus kann der Agent einen kompakten Operating Report erstellen:

• Runs und aktive externe Organisationen
• Completion Rate
• Trigger Mix uber Web, CLI, Schedules und Non-Zero Routes
• Model Mix
• Provider Mode
• Paid Org Activity
• Dormant Paid Orgs
• Neue zahlende Signups und Trialing Orgs
• Churn Watch
• 30-Tage-Segmentierung
• Registration-to-Run Retention
• First-Run Retention

Das ist genau die Art Report, die ein Founder-Team braucht. Er braucht keine rohen Prompts. Er braucht keine rohen E-Mails. Er braucht keinen Produktions-Schreibzugriff.

Er braucht die Fahigkeit, Produktfakten korrekt zu verbinden.

In einem Lauf fand der Agent, dass wenige aktive externe Organisationen den Grossteil des Volumens trugen, dass mehrere zahlende Organisationen still geworden waren und dass neue Registrierungskohorten einen scharfen Aktivierungsabfall zeigten, vermutlich weil Spam-Registrierungen den Nenner aufblahten. Das sind Dinge, die ein Founder schnell sehen sollte, nicht Wochen spater in einem Dashboard Review.

Ein zweites Beispiel: Trial-Abuse Economics

Maskierte Produktdaten sind auch fur Fragen nutzlich, die keine klassischen BI-Charts sind.

Bei Trial Abuse war die nutzliche Metrik nicht der gesamte Compute-Verbrauch. Total Spend ware zugunsten alterer Accounts verzerrt, weil sie mehr Zeit hatten, Credits zu verbrauchen. Die bessere Frage war:

Wie viel Trial Compute verbrennt ein neuer Account in den ersten Stunden nach Signup?

Mit MaskDB hat der Agent Compute-Verbrauch in vergleichbaren Fenstern nach Registrierung gemessen. Er nutzte Credit-Verbrauch aus Usage Events, Registrierungszeitpunkte aus Org Metadata und Subscription State, um Trial Economics von Paid Usage zu trennen.

Nachdem die Patrol live war, fiel der durchschnittliche Trial Compute in den ersten Stunden nach Signup um mehr als 80 Prozent. Der Heavy-Burn-Tail verschwand fast. Beim 90. Perzentil fiel der Trial Compute in den ersten Stunden von etwa 4,05 USD auf etwa 0,26 USD, ein Ruckgang um 94 Prozent.

Diese Zahl ist nicht nur ein Analytics-Punkt. Sie verandert die operative Sicht auf das Geschaft. Sie zeigt dem Founder-Team, dass Abuse nicht nur erkannt wurde, sondern dass sich die Unit Economics des Trials in die richtige Richtung bewegten.

Und das war moglich, weil die Datenbank die Wahrheit hatte, wahrend der maskierte Branch diese Wahrheit fur Agent-Analyse sicher machte.

Ein drittes Beispiel: Modellkosten im echten Produkt

Preisseiten und Benchmark Sheets sind nutzlich, beantworten aber nicht die Frage, die Founder wirklich stellen:

Was kostet dieses Modell in unserem echten Produkt, uber echte Runs hinweg?

Mit MaskDB verglich der Agent historische Chat Runs, indem er Run Records mit dem zum Run-Zeitpunkt ausgewahlten Modell verband und berechnete Credits aus Usage Events aggregierte.

Diese Unterscheidung ist wichtig. Man sollte historische Runs nicht anhand des aktuellen Default Model Providers eines Nutzers attribuieren, weil Defaults sich andern. Das zum Run-Zeitpunkt gewahlte Modell ist die Source of Truth.

In unserer Analyse hatte DS v4 Pro einen medianen Model-Credit-Verbrauch pro Chat Run von etwa 49 Prozent von Sonnet. Anders gesagt: Der reale mediane Chat Run war auf dieser Route ungefahr 51 Prozent gunstiger.

Auch das ist Founder-Level BI. Es verbindet Produktverhalten, Infrastrukturkosten und Modellstrategie. Es braucht kein neues Warehouse. Es braucht sicheren Zugriff auf die richtigen relationalen Daten.

Das ersetzt ein Warehouse nicht fur immer

Es gibt einen Punkt, an dem ein Unternehmen einen formaleren Data Stack braucht.

Wenn Metriken starke semantische Governance brauchen, wenn viele Teams dieselben Definitionen verwenden, wenn historische Backfills komplex werden, wenn Dashboards Teil des Betriebssystems werden, dann kann ein Warehouse oder Lakehouse die richtige Antwort sein.

Aber viele Startups greifen zu fruh nach dieser Antwort.

Wenn man ein kleines Founder-Team ist, sollte das erste BI-System helfen, Fragen zu beantworten, nicht ein zweites Produkt erzeugen, das gepflegt werden muss. Eine maskierte Datenbank kann die Brucke sein. Sie tut nicht so, als ware Data Modeling unwichtig. Sie erkennt an, dass die Produktdatenbank bereits die Beziehungen enthalt, die fur die nachsten Entscheidungen gebraucht werden.

Der Agent ersetzt kein Urteil. Er macht die erste Version der Analyse gunstiger.

Das Muster fur Founder-Teams

Das Muster ist einfach:

1. Die Produktdatenbank als erste Source of Truth behandeln.
2. Rohe Produktion nie an Agents geben.
3. Einen produktionsahnlichen Branch nutzen, keinen handgebauten Beispieldatensatz.
4. Sensible Spalten vor dem Zugriff statisch maskieren.
5. Opake Join-IDs erhalten, damit Analyse funktioniert.
6. Den Branch uber eine Read-only-Rolle freigeben.
7. Agents den Analysten-Loop uber MaskDB und die umliegenden Tools laufen lassen.

So bekommt ein Founder-Team ein nutzliches Betriebssystem, ohne zuerst eine komplette Datenplattform zu bauen.

Es schafft auch eine sauberere Security-Haltung. Der Agent hat eine harte Grenze. Die Datenbank, die er sieht, wurde bereits transformiert. Die Rolle, die er nutzt, kann nicht schreiben. Die Reports, die er erzeugt, konnen auf Hashes oder Aggregate beschrankt werden.

Das ist die Balance, die wir bei VM0 wollten: Privacy und Security als Grundlage, nicht als Tradeoff, und gleichzeitig ein viel schnellerer Weg fur das Founder-Team, das Geschaft zu verstehen.

Bevor man einen Data Lake baut, sollte man fragen, ob ein maskierter Read-only Branch der Produktdatenbank die nachsten 20 Fragen des Teams beantworten kann.

Fur uns war das der schnellere Weg zu BI.

Quellen

• Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
• Neon fork of PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer