BI utan en datalake

De flesta startup-BI-projekt börjar för tidigt och för stort.

En grundare ställer en enkel fråga: "Kommer användare från den här kanalen tillbaka efter sitt första körning?" Svaret borde vara en databasfråga. Istället blir det ofta ett plattformsprojekt: koppla varje källa, bygg ett warehouse, definiera händelser, rensa identiteter, koppla dashboards och vänta.

Det arbetet blir till slut viktigt. Men för ett litet team kan det vara fel första steg. Produktdatabasen vet redan det mesta som grundaren behöver veta. Den vet vem som registrerat sig, vem som kört något, vad de använde, vad det kostade, vad som misslyckades och om de kom tillbaka.

Det verkliga problemet är inte var sanningen finns. Det är hur man låter en AI-agent analysera den sanningen utan att exponera den råa produktionsdatabasen.

Det är mönstret vi använder på VM0: en maskerad, skrivskyddad Neon-gren som ger våra AI-agenter tillräckligt med sanning för att köra BI, utan att ge dem data de aldrig borde se.

Grundarproblemet: frågorna kommer innan datateamet

Tidiga bolag saknar inte frågor. De saknar tid.

Varje dag vill grundarteamet veta saker som:

• Blev gårdagens trafik riktiga användare?
• Vilka registreringskanaler ger personer som faktiskt kör något?
• Kommer användare som kör för första gången tillbaka efter 7 eller 30 dagar?
• Vilka betalande konton har blivit tysta?
• Vilken modellväg driver kostnaden?
• Missbrukar testanvändare beräkningskraft innan de konverterar?
• Har produktens hälsa blivit bättre eller sämre sedan igår?

Ingen av dessa frågor är ovanliga. De är startupens operativa rytm.

Men att besvara dem med traditionell BI innebär mycket merarbete. Ofta börjar man med att flytta data från produktdatabasen till ett annat system. Sedan normaliserar man, definierar mätetal, bygger om relationer och sätter upp dashboards. Teamet får en renare analysstack, men grundaren får ofta vänta dagar eller veckor på ett svar som kunde ha börjat som en SQL-fråga.

För en liten startup kan det vara bakvänt. Du behöver inte en komplett dataplattform för att ställa dina första 20 operativa frågor. Du behöver ett säkert sätt att fråga den sanning du redan har.

Databasen är redan sanningskällan

På VM0 innehåller produktdatabasen de fakta som är avgörande för många grundarbeslut:

• Organisationer och användare
• Registrerings- och prenumerationsstatus
• AI-agentkörningar och scheman
• Kreditförbrukning och användningshändelser
• Valda modeller och leverantörsvägar
• Connector-status
• Felstatus och tidsstämplar

De relationerna finns redan där. De är färskare än någon nedströms dashboard och speglar hur produkten faktiskt fungerar.

Detta är viktigt eftersom många tidiga BI-frågor är relationella. En grundare vill inte bara ha sidvisningar eller körningsantal. De vill koppla beteenden över hela systemet:

Av de användare som registrerade sig via den här kanalen, hur många körde något dag noll, och hur många kom tillbaka efter sin första körning?

Eller:

Vilka betalande organisationer har inte kört något de senaste 7 dagarna, och såg de tidigare aktiva ut?

Eller:

Hur mycket beräkningskraft förbrukade nya testkonton under sina första 6 timmar, före och efter vi ändrade vårt missbruksbevakningssystem?

De frågorna hör naturligt hemma i produktdatabasen. De blir mycket svårare när varje svar börjar med att flytta data till en separat plattform.

Den osäkra genvägen är rå produktionsåtkomst

Den lockande genvägen är uppenbar: låt bara AI-agenten fråga produktionen.

Det är inte acceptabelt.

En produktionsdatabas kan innehålla det mest känsliga i bolaget: e-postadresser, prompts, chattinnehåll, inloggningsuppgifter, krypterad leverantörsdata, loggar, felmeddelanden, API-nycklar och interna driftuppgifter. Även om en AI-agent är försiktig skapar rå åtkomst ett gränsproblem. Agenten kan se för mycket. Ett misstag i en fråga, rapport eller skärmdump kan läcka information som teamet aldrig tänkt exponera.

Skrivåtkomst är ännu värre. BI ska inte kunna ändra produktionen. En analytiker, mänsklig eller AI-agent, ska inte vara ett felkommando från att ändra användardata.

Så frågan är inte om AI-agenter kan skriva SQL. Det kan de. Frågan är om du kan ge dem tillräckligt med sanning för att vara användbara, samtidigt som integritet och säkerhet är hårda krav.

För oss är de kraven själva poängen:

• AI-agenter ska inte se råa prompts.
• AI-agenter ska inte se råa e-postadresser.
• AI-agenter ska inte se inloggningsuppgifter eller hemligheter.
• AI-agenter ska inte se känsliga fritextloggar.
• AI-agenter ska inte ha skrivåtkomst till BI-källan.
• Grundarteamet ska ändå snabbt kunna ställa praktiska operativa frågor.

Det är formen på det system vi behövde.

Den säkra mellanvägen: en maskerad, skrivskyddad databas

Neon möjliggör ett användbart mönster eftersom grenar är billiga, isolerade kopior av en Postgres-databas. Du kan skapa en produktionslik gren, transformera den och exponera den istället för produktionen.

På VM0 använder vi detta för att skapa det vi kallar MaskDB.

Flödet är enkelt:

1. Börja från produktions-Neon-huvudgrenen.
2. Skapa en ny gren enligt schema.
3. Installera PostgreSQL Anonymizer och VM0-specifika maskeringshjälpmedel.
4. Applicera säkerhetsetiketter för känsliga kolumner.
5. Kör statisk anonymisering på grenen.
6. Applicera slutliga anpassade masker för fält som kräver särskild hantering.
7. Skapa en masked_readonly-roll med SELECT-åtkomst.
8. Låt AI-agenter fråga den rollen, inte produktionen.

Det viktiga är att maskeringen är statisk. Känsliga värden skrivs om på den maskerade grenen innan AI-agenten ansluter. Det skiljer sig från att varje nedströmsfråga måste komma ihåg vad som inte ska väljas. Gränsen är själva grenen.

I vår MaskDB är inloggningsuppgifter och hemligheter maskerade. E-post och telefonnummer är delvis maskerade. Användarinnehåll som prompts, chattmeddelanden, schemalagda prompts och agentutdata tas bort. Feltext reduceras till en klass istället för full stack eller meddelande. Tabeller som aldrig ska analyseras kan tas bort helt.

Samtidigt behålls opaka identifierare som org_id, user_id och clerk_user_id så att de går att koppla ihop. Det är det som gör BI möjligt. Vi behöver inte att AI-agenten vet en persons e-postadress eller prompttext. Vi behöver att den vet att samma organisation registrerade sig, körde en uppgift, förbrukade krediter, tecknade prenumeration, blev inaktiv eller kom tillbaka senare.

Den balansen är hela poängen: maskera det läsbara och känsliga, bevara den relationella ryggraden.

Vad AI-agenter kan göra när gränsen finns

När den maskerade skrivskyddade databasen finns kan AI-agenten snabbt bli användbar.

Den kan ställa frågor direkt mot produktdata:

• 7- och 30-dagars användarretention
• Registrering-till-första-körning-aktivering
• Första-körningsbaserad retention
• Betalande orgs inaktivitet
• Prenumerationsstatus och churn-bevakning
• Modellanvändning per vald modell
• Inbyggda kontra användarleverantörsvägar
• Testanvändares beräkningsförbrukning
• Kostnad per körning per modell
• Fel- och slutförandegrad per kohort

Den kan också kombinera denna databas-sanning med systemen runt omkring.

Vår Morning Brief hämtar från Plausible, Axiom, Sentry, Google Ads, GitHub och andra operativa källor. Databasen visar vad användare och organisationer gjort. Plausible visar vad som hänt på sajten. PostHog kan ge produktevent-kontekst. Axiom visar vad som hänt i loggar och anrop. Sentry fångar fel. Stripe och Clerk förklarar fakturering och identitet. GitHub visar ingenjörsgenomströmning.

Poängen är inte att ersätta varje verktyg med SQL. Poängen är att låta AI-agenten koppla ihop de fakta som grundare faktiskt bryr sig om.

Till exempel:

Betald Google skickade mer trafik än organiskt igår. Nådde de användarna faktiskt första körning, eller fastnade de i toppen av tratten?

Eller:

Vi ändrade testmissbruksfiltret. Förbrukade nya testkonton mindre beräkningskraft under sina första timmar?

Eller:

Den här modellvägen är billigare per körning. Syns det i verklig historisk chattanvändning, eller bara i pristeori?

Detta är inte dashboard-frågor. Det är operativa frågor. De ändras vecka för vecka, ibland dag för dag. En AI-agent med säker databasåtkomst kan besvara dem utan att be utveckling bygga en ny vy varje gång.

Ett riktigt exempel: retention och extern användarhälsa

En av våra dagliga interna analyser tittar på extern användarhälsa de senaste 24 timmarna.

Rapporten börjar från MaskDB och tillämpar sedan en strikt exkluderingslista. Interna VM0-organisationer tas bort. Clerk-bannade eller låsta spam-organisationer tas bort. Samma exkludering gäller överallt, även för registreringar och retentionkohorter, så nämnare är spårbara.

Därifrån kan AI-agenten ta fram en kompakt operativ rapport:

• Körningar och aktiva externa organisationer
• Slutförandegrad
• Trigger-mix över web, CLI, scheman och icke-Zero-vägar
• Modellmix
• Leverantörsläge
• Betalande org-aktivitet
• Inaktiva betalande orgs
• Nya betalande registreringar och testande organisationer
• Churn-bevakning
• 30-dagars användarsegmentering
• Registrering-till-körning-retention
• Första-körningsretention

Detta är precis den typ av rapport ett grundarteam behöver. Den kräver inte råa prompts. Den kräver inte råa e-postadresser. Den kräver inte skrivåtkomst till produktionen.

Den kräver förmågan att koppla produktfakta korrekt.

Vid ett tillfälle fann AI-agenten att ett fåtal aktiva externa organisationer stod för merparten av volymen, att flera betalande organisationer blivit tysta och att nya registreringskohorter visade en skarp aktiveringsklippa, troligen orsakad av spamregistreringar som blåste upp nämnaren. Det är sådant en grundare bör se snabbt, inte upptäcka veckor senare i en dashboardgenomgång.

Ett andra exempel: testmissbruksekonomi

Maskerad produktdata är också användbar för frågor som inte är klassiska BI-diagram.

När vi tittade på testmissbruk var det användbara måttet inte total förbrukad beräkningskraft. Totalen skulle snedvridas mot äldre konton, eftersom de haft mer tid att förbruka krediter. Den bättre frågan var:

Hur mycket testberäkning förbrukar ett nytt konto under sina första timmar efter registrering?

Med MaskDB mätte AI-agenten beräkningsförbrukning i matchade tidsfönster efter registrering. Den använde kreditförbrukning från användningshändelser, registreringstidsstämplar från org-metadata och prenumerationsstatus för att särskilja testekonomi från betald användning.

Efter att filtret infördes sjönk genomsnittlig testberäkning under de första timmarna efter registrering med mer än 80%. Den tunga svansen försvann nästan. På 90:e percentilen föll testberäkningen under första timmarna från cirka $4.05 till cirka $0.26, en minskning med 94%.

Det talet är inte bara en analysnotering. Det förändrar den operativa synen på verksamheten. Det visar grundarteamet att missbruk inte bara upptäcktes, utan att enhetsekonomin för testperioden rörde sig åt rätt håll.

Och det var möjligt eftersom databasen hade sanningen, medan den maskerade grenen gjorde det säkert för en AI-agent att analysera den.

Ett tredje exempel: modellkostnad i verklig produkt

Prissidor och benchmarks är användbara, men de svarar inte på frågan grundare faktiskt bryr sig om:

Vad kostar den här modellen i vår riktiga produkt, över riktiga körningar?

Med MaskDB jämförde AI-agenten historiska chattkörningar genom att koppla körningsposter med vald modell vid körning och summera debiterade krediter från användningshändelser.

Den skillnaden är viktig. Du ska inte tillskriva historiska körningar till användarens nuvarande standardmodell, eftersom standarder ändras. Den valda modellen vid körning är sanningskällan.

I vår analys hade DS v4 Pro en medianmodell-kreditkostnad per chattkörning på cirka 49% av Sonnet's. Med andra ord var den verkliga medianchattkörningen ungefär 51% billigare på den vägen.

Återigen, detta är grundarnivå-BI. Det kopplar produktbeteende, infrastrukturkostnad och modellstrategi. Det kräver inget nytt warehouse. Det kräver säker åtkomst till rätt relationella data.

Detta ersätter inte ett warehouse för alltid

Det kommer en punkt när ett bolag behöver en mer formell datastack.

När mätetal kräver stark semantisk styrning, när många team är beroende av samma definitioner, när historiska backfills blir komplexa, när dashboards blir en del av operativsystemet, kan ett warehouse eller lakehouse vara rätt svar.

Men många startups väljer det svaret för tidigt.

Om du är ett litet grundarteam bör ditt första BI-system hjälpa dig att besvara frågor, inte skapa en andra produkt att underhålla. En maskerad databas kan vara bron. Det låtsas inte att datamodellering inte spelar roll. Det erkänner att produktdatabasen redan innehåller de relationer du behöver för nästa beslut.

AI-agenten tar inte bort behovet av omdöme. Den gör första versionen av analysen billigare att köra.

Mönstret för grundarteam

Mönstret är enkelt:

1. Behandla produktdatabasen som första sanningskälla.
2. Exponera aldrig rå produktion för AI-agenter.
3. Använd en produktionslik gren, inte ett handbyggt exempeldata.
4. Maskera känsliga kolumner statiskt före åtkomst.
5. Bevara opaka kopplings-ID så analysen fungerar.
6. Exponera grenen via en skrivskyddad roll.
7. Låt AI-agenter köra analysturen över den maskerade DB:n och kringliggande verktyg.

Detta ger ett grundarteam ett användbart operativsystem utan att först bygga en full dataplattform.

Det skapar också en renare säkerhetsprofil. AI-agenten har en tydlig gräns. Databasen den ser är redan transformerad. Rollen den använder kan inte skriva. Rapporterna kan begränsas till hashade eller aggregerade ID.

Det är balansen vi ville ha på VM0: integritet och säkerhet som grund, inte kompromiss, samtidigt som grundarteamet får ett mycket snabbare sätt att förstå verksamheten.

Innan du bygger ett datalager, fråga om en maskerad, skrivskyddad gren av din produktdatabas kan besvara de nästa 20 frågor ditt team faktiskt har.

För oss var det den snabbare vägen till BI.

Källor

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