BI Without a Data Lake

Most startup BI projects begin too early and too big.

A founder asks a simple question: "Are users from this channel coming back after their first run?" The answer should be a query. Instead, it often turns into a platform project: connect every source, build a warehouse, define events, clean identities, wire dashboards, and wait.

That work eventually matters. But for a small team, it can be the wrong first move. The product database already knows most of what the founder needs to know. It knows who signed up, who ran something, what they used, how much it cost, what failed, and whether they came back.

The real problem is not where the truth lives. It is how to let an agent analyze that truth without exposing the raw production database.

That is the pattern we use at VM0: a masked, read-only Neon branch that gives our agents enough truth to run BI, without giving them the data they should never see.

The founder problem: the questions arrive before the data team

Early-stage companies do not lack questions. They lack time.

Every day, the founder team wants to know things like:

• Did yesterday's traffic turn into real users?
• Which signup channels produce people who actually run something?
• Do first-run users come back after 7 or 30 days?
• Which paid accounts are going quiet?
• Which model route is driving cost?
• Are trial abusers burning compute before they convert?
• Did product health get better or worse since yesterday?

None of these questions are exotic. They are the operating rhythm of a startup.

But answering them with the traditional BI playbook creates a lot of overhead. You usually start by moving data out of the product database and into another system. Then you normalize it, define metrics, rebuild relationships, and set up dashboards. The team gets a cleaner analytics stack, but the founder often waits days or weeks for an answer that could have started as a SQL query.

For a small startup, that tradeoff can be backwards. You do not need a complete data platform to ask your first 20 operating questions. You need a safe way to query the source of truth you already have.

The database is already the source of truth

At VM0, the product database contains the facts that matter for many founder-level decisions:

• Organizations and users
• Signup and subscription state
• Agent runs and schedules
• Credit consumption and usage events
• Selected models and provider routes
• Connector state
• Failure state and timestamps

Those relationships are already there. They are fresher than any downstream dashboard, and they reflect how the product actually works.

This matters because many early BI questions are relational. A founder does not only want page views or run counts. They want to connect behavior across the system:

Of the users who registered from this channel, how many ran something on day zero, and how many came back after their first run?

Or:

Which paid organizations have not run anything in the last 7 days, and did they previously look active?

Or:

How much compute did new trial accounts burn in their first 6 hours, before and after we changed our abuse patrol?

Those questions sit naturally in the product database. They become much harder when every answer starts with moving data into a separate platform.

The unsafe shortcut is raw production access

The tempting shortcut is obvious: just let the agent query production.

That is not acceptable.

A production database can contain the most sensitive material in the company: email addresses, prompts, chat content, credentials, encrypted provider state, logs, error messages, API keys, and internal operational records. Even if an agent is careful, raw access creates a boundary problem. The agent can see too much. A mistake in a query, a report, or a screenshot can leak information the team never intended to expose.

Write access is even worse. BI should not be able to mutate production. An analyst, human or agentic, should not be one bad command away from changing user data.

So the question is not whether agents can write SQL. They can. The question is whether you can give them enough truth to be useful while keeping privacy and safety as hard constraints.

For us, those constraints are the point:

• Agents should not see raw prompts.
• Agents should not see raw emails.
• Agents should not see credentials or secrets.
• Agents should not see sensitive free-text logs.
• Agents should not have write access to the BI source.
• The founder team should still be able to ask practical operating questions quickly.

That is the shape of the system we needed.

The safe middle ground: a masked, read-only database

Neon makes a useful pattern possible because branches are cheap, isolated copies of a Postgres database. You can create a production-like branch, transform it, and expose that branch instead of production itself.

At VM0, we use this to create what we call MaskDB.

The flow is simple:

1. Start from the production Neon parent branch.
2. Create a fresh branch on a schedule.
3. Install PostgreSQL Anonymizer and VM0-specific masking helpers.
4. Apply security labels for sensitive columns.
5. Run static anonymization on the branch.
6. Apply final custom masks for fields that need special handling.
7. Create a masked_readonly role with SELECT access.
8. Let agents query that role, not production.

The important detail is that the masking is static. Sensitive values are rewritten on the masked branch before the agent connects. This is different from asking every downstream query to remember what not to select. The branch itself is the boundary.

In our MaskDB, credentials and secrets are redacted. Emails and phone numbers are partially masked. User content such as prompts, chat messages, schedule prompts, and agent outputs is removed. Error text is reduced to a class rather than a full stack or message. Tables that should never appear in analysis can be dropped entirely.

At the same time, opaque identifiers like org_id, user_id, and clerk_user_id stay joinable. That is what makes BI possible. We do not need the agent to know a person's email address or prompt text. We do need it to know that the same organization registered, ran a task, consumed credits, subscribed, went dormant, or came back later.

That balance is the whole point: mask the human-readable and sensitive material, preserve the relational spine.

What agents can do once the boundary exists

Once the masked read-only database exists, the agent can become useful very quickly.

It can ask questions directly against product data:

• 7-day and 30-day user retention
• Registration-to-first-run activation
• First-run-anchored retention
• Paid org dormancy
• Subscription state and churn watch
• Model usage by selected model
• Built-in vs user-provider routes
• Trial compute consumption
• Cost per run by model
• Failure rate and completion rate by cohort

It can also combine that database truth with the systems around it.

Our Morning Brief pulls from Plausible, Axiom, Sentry, Google Ads, GitHub, and other operational sources. The database tells us what users and orgs did. Plausible tells us what happened on the site. PostHog can help with product-event context. Axiom tells us what happened in logs and request paths. Sentry catches errors. Stripe and Clerk help explain billing and identity. GitHub shows engineering throughput.

The point is not to replace every tool with SQL. The point is to let the agent connect the facts that founders actually care about.

For example:

Paid Google sent more traffic than organic yesterday. Did those users actually reach first run, or did they stop at the top of the funnel?

Or:

We changed the trial-abuse patrol. Did new trial accounts burn less compute in their first few hours?

Or:

This model route is cheaper per run. Does that show up in real historical chat usage, or only in pricing theory?

Those are not dashboard questions. They are operating questions. They change week to week, sometimes day to day. An agent with safe database access can answer them without asking engineering to build a new view every time.

A real example: retention and external user health

One of our daily internal analyses looks at external user health over the trailing 24 hours.

The report starts from MaskDB, then applies a strict exclusion set. Internal VM0 orgs are removed. Clerk-banned or locked spam orgs are removed. That same exclusion set is applied everywhere, including registration counts and retention cohorts, so denominators stay auditable.

From there, the agent can produce a compact operating report:

• Runs and active external orgs
• Completion rate
• Trigger mix across web, CLI, schedules, and non-Zero routes
• Model mix
• Provider mode
• Paid org activity
• Dormant paid orgs
• New paid signups and trialing orgs
• Churn watch
• 30-day user segmentation
• Registration-to-run retention
• First-run retention

This is exactly the kind of report a founder team needs. It does not require raw prompts. It does not require raw emails. It does not require production write access.

It does require the ability to join product facts correctly.

In one run, the agent found that a small number of active external orgs were driving most of the volume, that several paid orgs had gone quiet, and that recent registration cohorts showed a sharp activation cliff likely caused by spam registrations inflating the denominator. Those are the kinds of things a founder should see quickly, not discover weeks later in a dashboard review.

A second example: trial abuse economics

Masked product data is also useful for questions that are not classic BI charts.

When we looked at trial abuse, the useful metric was not total compute spent. Total spend would be biased toward older accounts, because they had more time to consume credits. The better question was:

How much trial compute does a new account burn in its first few hours after signup?

Using MaskDB, the agent measured compute consumption in matched windows after registration. It used credit consumption from usage events, registration timestamps from org metadata, and subscription state to separate trial economics from paid usage.

After the patrol went live, average trial compute burned in the first hours after signup dropped by more than 80%. The heavy-burn tail nearly disappeared. At the 90th percentile, first-hours trial compute fell from about $4.05 to about $0.26, a 94% drop.

That number is not just an analytics point. It changes the operating view of the business. It tells the founder team that abuse was not only being detected, but that the unit economics of the trial were moving in the right direction.

And it was possible because the database had the truth, while the masked branch made it safe for an agent to analyze that truth.

A third example: model cost in the real product

Pricing pages and benchmark sheets are useful, but they do not answer the question founders actually care about:

What does this model cost in our real product, across real runs?

Using MaskDB, the agent compared historical chat runs by joining run records with the model selected at run time and aggregating charged credits from usage events.

That distinction matters. You should not attribute historical runs using the user's current default model provider, because defaults change. The selected model at run time is the source of truth.

In our analysis, DS v4 Pro had a median model-credit cost per chat run that was about 49% of Sonnet's. In other words, the real median chat run was roughly 51% cheaper on that route.

Again, this is founder-level BI. It connects product behavior, infrastructure cost, and model strategy. It does not require a new warehouse. It requires safe access to the right relational data.

This is not a forever replacement for a warehouse

There is a point where a company needs a more formal data stack.

When metrics need strong semantic governance, when many teams depend on the same definitions, when historical backfills become complex, when dashboards become part of the operating system, a warehouse or lakehouse can be the right answer.

But many startups reach for that answer too early.

If you are a small founder team, your first BI system should help you answer questions, not create a second product to maintain. A masked database can be the bridge. It is not pretending that data modeling does not matter. It is recognizing that the product database already contains the relationships you need for the next set of decisions.

The agent does not remove the need for judgment. It makes the first version of the analysis cheaper to run.

The pattern for founder teams

The pattern is simple:

1. Treat the product database as the first source of truth.
2. Never expose raw production to agents.
3. Use a production-like branch, not a hand-built sample dataset.
4. Statically mask sensitive columns before access.
5. Preserve opaque join identifiers so analysis still works.
6. Expose the branch through a read-only role.
7. Let agents run the analyst loop across the masked DB and the surrounding tools.

This gives a founder team a useful operating system without building a full data platform first.

It also creates a cleaner security posture. The agent has a hard boundary. The database it sees has already been transformed. The role it uses cannot write. The reports it produces can be constrained to hashed or aggregate identifiers.

That is the balance we wanted at VM0: privacy and security as the floor, not the tradeoff, while still giving the founder team a much faster way to understand the business.

Before you build a data lake, ask whether a masked, read-only branch of your product database can answer the next 20 questions your team actually has.

For us, that was the faster path to BI.

Sources

• 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