BI sin un data lake

La mayoria de los proyectos de BI en startups empiezan demasiado pronto y demasiado grandes.

Un founder hace una pregunta simple: "Los usuarios que llegan desde este canal vuelven despues de su primer run?" La respuesta deberia ser una consulta. Pero a menudo se convierte en un proyecto de plataforma: conectar todas las fuentes, construir un warehouse, definir eventos, limpiar identidades, montar dashboards y esperar.

Ese trabajo termina siendo importante. Pero para un equipo pequeno, puede ser el primer paso equivocado. La base de datos del producto ya sabe casi todo lo que el founder necesita saber. Sabe quien se registro, quien ejecuto algo, que uso, cuanto costo, que fallo y si esa persona volvio.

El problema real no es donde vive la verdad. Es como dejar que un agente analice esa verdad sin exponer la base de datos de produccion sin procesar.

Ese es el patron que usamos en VM0: una rama de Neon enmascarada y de solo lectura que da a nuestros agentes suficiente verdad para hacer BI, sin darles los datos que nunca deberian ver.

El problema del founder: las preguntas llegan antes que el equipo de datos

Las empresas en etapa temprana no carecen de preguntas. Carecen de tiempo.

Cada dia, el founder team quiere saber:

• El trafico de ayer se convirtio en usuarios reales?
• Que canales de signup traen personas que realmente ejecutan algo?
• Los usuarios que hacen su primer run vuelven despues de 7 o 30 dias?
• Que cuentas pagas se estan quedando en silencio?
• Que ruta de modelo esta generando costo?
• Los abusadores del trial estan quemando compute antes de convertir?
• La salud del producto mejoro o empeoro desde ayer?

Nada de esto es exotico. Es el ritmo operativo de una startup.

Pero responderlo con el manual tradicional de BI crea mucho overhead. Normalmente empiezas moviendo datos fuera de la base del producto hacia otro sistema. Luego normalizas, defines metricas, reconstruyes relaciones y preparas dashboards. El equipo obtiene un stack analitico mas limpio, pero el founder espera dias o semanas por una respuesta que podria haber empezado como una consulta SQL.

Para una startup pequena, ese orden puede estar al reves. No necesitas una plataforma de datos completa para responder las primeras 20 preguntas operativas. Necesitas una forma segura de consultar la fuente de verdad que ya tienes.

La base de datos ya es la fuente de verdad

En VM0, la base de datos del producto contiene los hechos que importan para muchas decisiones de founder:

• Organizaciones y usuarios
• Estado de signup y suscripcion
• Agent runs y schedules
• Consumo de credits y usage events
• Modelos seleccionados y rutas de provider
• Estado de connectors
• Estado de fallos y timestamps

Esas relaciones ya existen. Son mas frescas que cualquier dashboard posterior y reflejan como funciona realmente el producto.

Esto importa porque muchas preguntas tempranas de BI son relacionales. Un founder no quiere solo page views o conteos de runs. Quiere conectar comportamiento en todo el sistema:

De los usuarios que se registraron desde este canal, cuantos ejecutaron algo el dia cero y cuantos volvieron despues de su primer run?

O:

Que organizaciones pagas no ejecutaron nada en los ultimos 7 dias, aunque antes parecian activas?

O:

Cuanto compute quemaron las nuevas cuentas trial en sus primeras 6 horas, antes y despues de cambiar nuestra abuse patrol?

Estas preguntas viven naturalmente en la base de datos del producto. Se vuelven mucho mas dificiles cuando cada respuesta empieza moviendo datos a una plataforma separada.

El atajo inseguro es acceso directo a produccion

El atajo tentador es obvio: dejar que el agente consulte produccion directamente.

Eso no es aceptable.

Una base de datos de produccion puede contener el material mas sensible de la compania: emails, prompts, contenido de chats, credenciales, estado cifrado de providers, logs, mensajes de error, API keys y registros operativos internos. Incluso si un agente es cuidadoso, el acceso raw crea un problema de frontera. El agente ve demasiado. Un error en una consulta, un reporte o una captura puede filtrar informacion que el equipo nunca quiso exponer.

El acceso de escritura es aun peor. BI no deberia poder mutar produccion. Un analista, humano o agentico, no deberia estar a un mal comando de cambiar datos de usuarios.

La pregunta no es si los agentes pueden escribir SQL. Pueden. La pregunta es si puedes darles suficiente verdad para ser utiles mientras privacidad y seguridad siguen siendo limites duros.

Para nosotros, esos limites son el punto:

• Los agentes no deberian ver prompts raw.
• Los agentes no deberian ver emails raw.
• Los agentes no deberian ver credenciales o secretos.
• Los agentes no deberian ver logs sensibles de texto libre.
• Los agentes no deberian tener escritura sobre la fuente de BI.
• El founder team aun deberia poder hacer preguntas operativas rapidamente.

Esa era la forma del sistema que necesitabamos.

El punto medio seguro: una base enmascarada y de solo lectura

Neon hace posible un patron util porque las branches son copias livianas y aisladas de una base Postgres. Puedes crear una branch similar a produccion, transformarla y exponer esa branch en lugar de la produccion real.

En VM0, llamamos a esto MaskDB.

El flujo es simple:

1. Partir de la production parent branch de Neon.
2. Crear una branch fresca de forma programada.
3. Instalar PostgreSQL Anonymizer y helpers de enmascarado propios de VM0.
4. Aplicar security labels a columnas sensibles.
5. Ejecutar anonimizacion estatica en la branch.
6. Aplicar mascaras finales para campos especiales.
7. Crear un rol masked_readonly con acceso SELECT.
8. Dejar que los agentes consulten ese rol, no produccion.

El detalle importante es que el masking es estatico. Los valores sensibles se reescriben en la branch enmascarada antes de que el agente se conecte. Esto es distinto de pedirle a cada consulta posterior que recuerde que no debe seleccionar. La branch misma es la frontera.

En nuestra MaskDB, credenciales y secretos se redactan. Emails y telefonos se enmascaran parcialmente. Contenido de usuarios como prompts, mensajes de chat, schedule prompts y outputs de agentes se elimina. El texto de errores se reduce a una clase en lugar de exponer stacks o mensajes completos. Tablas que nunca deberian aparecer en analisis pueden eliminarse por completo.

Al mismo tiempo, identificadores opacos como org_id, user_id y clerk_user_id siguen siendo joinables. Eso es lo que hace posible BI. No necesitamos que el agente conozca el email de una persona o el texto de sus prompts. Necesitamos que sepa que la misma organizacion se registro, ejecuto una tarea, consumio credits, se suscribio, se quedo dormida o volvio despues.

Ese equilibrio es todo el punto: enmascarar lo legible y sensible, preservar la columna vertebral relacional.

Que pueden hacer los agentes cuando existe esa frontera

Una vez que existe la base enmascarada y de solo lectura, el agente se vuelve util muy rapido.

Puede hacer preguntas directamente sobre datos de producto:

• Retencion de 7 y 30 dias
• Activacion de registro a primer run
• Retencion anclada en el primer run
• Organizaciones pagas dormidas
• Estado de suscripcion y churn watch
• Uso de modelos por modelo seleccionado
• Rutas built-in vs user-provider
• Consumo de compute en trials
• Costo por run por modelo
• Failure rate y completion rate por cohorte

Tambien puede combinar esa verdad de base de datos con los sistemas alrededor.

Nuestro Morning Brief toma datos de Plausible, Axiom, Sentry, Google Ads, GitHub y otras fuentes operativas. La base de datos dice que hicieron los usuarios y las organizaciones. Plausible dice que paso en el sitio. PostHog puede dar contexto de eventos de producto. Axiom muestra logs y request paths. Sentry captura errores. Stripe y Clerk explican billing e identidad. GitHub muestra throughput de engineering.

El punto no es reemplazar cada herramienta con SQL. El punto es permitir que el agente conecte los hechos que realmente importan a los founders.

Por ejemplo:

Paid Google envio mas trafico que organic ayer. Esos usuarios llegaron realmente a su primer run o se frenaron arriba del funnel?

O:

Cambiamos la trial-abuse patrol. Las nuevas cuentas trial queman menos compute en sus primeras horas?

O:

Esta ruta de modelo es mas barata por run. Eso aparece en el uso historico real de chat o solo en la teoria de precios?

Esas no son preguntas de dashboard. Son preguntas operativas. Cambian semana a semana, a veces dia a dia. Un agente con acceso seguro a la base puede responderlas sin pedir a engineering que construya una view nueva cada vez.

Un ejemplo real: retencion y salud de usuarios externos

Uno de nuestros analisis internos diarios mira la salud de usuarios externos en las ultimas 24 horas.

El reporte empieza desde MaskDB y luego aplica un conjunto estricto de exclusiones. Se eliminan organizaciones internas de VM0. Se eliminan organizaciones de spam baneadas o bloqueadas en Clerk. Ese mismo conjunto se aplica en todas las metricas, incluyendo conteos de registro y cohortes de retencion, para que los denominadores sean auditables.

A partir de ahi, el agente puede producir un reporte operativo compacto:

• Runs y organizaciones externas activas
• Completion rate
• Trigger mix en web, CLI, schedules y non-Zero routes
• Model mix
• Provider mode
• Actividad de paid orgs
• Paid orgs dormidas
• Nuevos signups pagos y trialing orgs
• Churn watch
• Segmentacion de 30 dias
• Registration-to-run retention
• First-run retention

Este es exactamente el tipo de reporte que necesita un founder team. No requiere prompts raw. No requiere emails raw. No requiere escritura en produccion.

Si requiere poder unir correctamente los hechos del producto.

En un run, el agente encontro que unas pocas organizaciones externas activas generaban la mayor parte del volumen, que varias organizaciones pagas se habian quedado en silencio y que las cohortes recientes de registro mostraban una caida fuerte de activacion, probablemente porque registros de spam inflaban el denominador. Eso es algo que un founder deberia ver rapido, no semanas despues en una revision de dashboards.

Un segundo ejemplo: economia del abuso de trials

Los datos de producto enmascarados tambien sirven para preguntas que no son charts clasicos de BI.

Cuando miramos trial abuse, la metrica util no era el compute total gastado. El gasto total estaria sesgado hacia cuentas antiguas, porque tuvieron mas tiempo para consumir credits. La mejor pregunta era:

Cuanto trial compute quema una cuenta nueva en sus primeras horas despues del signup?

Con MaskDB, el agente midio consumo de compute en ventanas comparables despues del registro. Uso consumo de credits desde usage events, timestamps de registro desde org metadata y subscription state para separar la economia de trials del uso pago.

Despues de activar la patrol, el compute promedio quemado por trials en las primeras horas despues del signup cayo mas de 80 por ciento. La cola de alto consumo casi desaparecio. En el percentil 90, el trial compute de las primeras horas cayo de unos 4,05 dolares a unos 0,26 dolares, una caida de 94 por ciento.

Ese numero no es solo un punto de analytics. Cambia la lectura operativa del negocio. Le dice al founder team que el abuso no solo se estaba detectando, sino que la economia unitaria del trial se estaba moviendo en la direccion correcta.

Y fue posible porque la base de datos tenia la verdad, mientras la branch enmascarada hacia seguro que un agente analizara esa verdad.

Un tercer ejemplo: costo de modelos en el producto real

Las paginas de precios y los benchmark sheets son utiles, pero no responden la pregunta que realmente importa a los founders:

Cuanto cuesta este modelo en nuestro producto real, a traves de runs reales?

Con MaskDB, el agente comparo runs historicos de chat uniendo los registros de run con el modelo seleccionado en ese momento y agregando credits cobrados desde usage events.

Esa distincion importa. No deberias atribuir runs historicos usando el provider default actual del usuario, porque los defaults cambian. El modelo seleccionado en el momento del run es la fuente de verdad.

En nuestro analisis, DS v4 Pro tuvo un costo mediano de model credits por chat run de alrededor del 49 por ciento de Sonnet. En otras palabras, el chat run mediano real fue aproximadamente 51 por ciento mas barato en esa ruta.

De nuevo, esto es BI de nivel founder. Conecta comportamiento de producto, costo de infraestructura y estrategia de modelos. No requiere un nuevo warehouse. Requiere acceso seguro a los datos relacionales correctos.

Esto no reemplaza un warehouse para siempre

Hay un punto en el que una empresa necesita un data stack mas formal.

Cuando las metricas necesitan governance semantica fuerte, cuando muchos equipos dependen de las mismas definiciones, cuando los backfills historicos se vuelven complejos, cuando los dashboards se vuelven parte del sistema operativo, un warehouse o lakehouse puede ser la respuesta correcta.

Pero muchas startups llegan a esa respuesta demasiado pronto.

Si eres un founder team pequeno, tu primer sistema de BI deberia ayudarte a responder preguntas, no crear un segundo producto que mantener. Una base enmascarada puede ser el puente. No finge que el data modeling no importa. Reconoce que la base de datos del producto ya contiene las relaciones que necesitas para las proximas decisiones.

El agente no reemplaza el juicio. Hace mas barata la primera version del analisis.

El patron para founder teams

El patron es simple:

1. Tratar la base de datos del producto como la primera fuente de verdad.
2. Nunca exponer produccion raw a agentes.
3. Usar una branch similar a produccion, no un dataset de ejemplo hecho a mano.
4. Enmascarar columnas sensibles de forma estatica antes del acceso.
5. Preservar identificadores opacos para que el analisis siga funcionando.
6. Exponer la branch mediante un rol de solo lectura.
7. Dejar que los agentes ejecuten el loop de analista sobre MaskDB y las herramientas alrededor.

Esto da al founder team un sistema operativo util sin construir primero una plataforma de datos completa.

Tambien crea una postura de seguridad mas limpia. El agente tiene una frontera dura. La base que ve ya fue transformada. El rol que usa no puede escribir. Los reportes que produce pueden limitarse a identificadores hasheados o agregados.

Ese es el equilibrio que queriamos en VM0: privacidad y seguridad como base, no como tradeoff, mientras damos al founder team una forma mucho mas rapida de entender el negocio.

Antes de construir un data lake, pregunta si una branch enmascarada y de solo lectura de la base de datos del producto puede responder las proximas 20 preguntas reales del equipo.

Para nosotros, ese fue el camino mas rapido hacia BI.

Fuentes

• 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