The Data Oracle

In a team of 4, founders are expected to wear a lot of hats. Data analytics has largely fallen to me: how do we track what’s important, how do we use data in decision making, all that stuff. But as anyone who’s been in an analyst role knows, putting together good dashboards and deep dives takes a ton of time.

We’ve tested plenty of product analytics tools: Posthog, Mixpanel, Hex, Metabase, to name a few. But in recent months, one tool has beaten them all, and not by small margins. I call it the data oracle.

Data Oracle

An oracle is a person, medium, or shrine (notably in ancient Greece) believed to deliver wise, prophetic, or divine counsel.

The hard thing about product analytics is that you usually don’t know what you’re looking for. You’re poking around, merging data in different ways, hoping a pattern surfaces. There are ten ways to answer any data question, and on a good day you’ll have time to test two.

Most of the work is creative: asking the right question. The SQL itself is the easy part, but writing it still drains mental capacity. Or you can copy-paste between ChatGPT and an SQL client but this is still dull, slow, and not particularly safe (one hallucinated UPDATE command and you’re restoring from backup).

So at the end of last year, we looked for a tool with proper AI integration that could run SQL in a safe environment. Hex and Metabase were the two contenders with decent AI support. However, both turned out to be built for a pre-AI world: the smart features are added on top of the core non-AI platform and 90% of the time you end up fighting the agent instead of asking questions. On top of that, both run €2-3K per year. For a bootstrapped company, that makes a big difference.

Building it ourselves

Our data oracle is, in essence, an Opus-powered chatbot connected to our Postgres database. Before anyone comes screaming about the safety implications of this, let me explain.

Read-only Postgres role

We created a dedicated Postgres user with SELECT access to a narrow set of analytics views, not the underlying tables. No PII or sensitive data could be accessed by the agent. In essence, it cannot see fields it shouldn’t, and it cannot write or edit anything. If the LLM hallucinates a DELETE, Postgres rejects it at the permission layer, not at the prompt layer. Prompt-level guardrails are useful but they’re suggestions, whereas database permissions are physical constraints.

Agent design

The agent has two tools:

• get_schema: This returns the full schema about the accessible fields. This gives the model the necessary context. We separated it into a tool call instead of just passing it via system prompt to save on tokens but could work either way.
• execute_query: The main function that runs the SQL. Restricted to SELECT, WITH and EXPLAIN queries.

The agent can chain multiple queries within a thread. Most real questions need 2-4 different queries: one to understand the shape of the data, one or two to answer, and sometimes one to sanity-check. Letting the model iterate inside a single thread is what makes it feel like a real analyst rather than a SQL autocomplete.

Here’s the system prompt:

You are a database analyst for Mindsera, a journaling & mental wellness platform. You answer questions about the production PostgreSQL database.

## Schema

All tables live in the analytics schema.

When necessary, call get_schema to load the full schema reference. Only call it when you need it again.

## Guidelines

- Call get_schema once, then go straight to execute_query.
- Only SELECT / WITH / EXPLAIN allowed.
- Use LIMIT on potentially large result sets.
- You may run multiple queries to build up an answer.
- After getting results, explain what they mean in plain language.
- Format numbers with separators and dates for readability.

Interface

The UI is a basic chatbot, built directly into our admin panel. You ask a question, you get an answer.

Answer:

What it actually feels like to use

Within a few weeks of launching, I’ve created 41 new threads with it. When discussing product improvements, we can pull it up mid-call, ask a question, and have an answer in 30 seconds. We’ve used it to better define our ICP, discover patterns about habit building, and much more. My cofounder can ask it questions without knowing anything about SQL.

The unlock isn’t that the oracle gives us answers we couldn’t get before. It’s that the time cost of asking a data question has dropped close to zero. When asking is quick, you ask more, and you ask better questions.

Safe to say, the quality and speed of our decision making has gone up immensely. It’s kinda like having the Dune Mentat dude available 24/7.

The bigger point

The best part: we control the prompts and the results, it’s one less platform to manage, and the data stays in-house. For a setup that took half a day and $15 per month to cover the tokens, not bad.

For years, the right answer was almost always “buy the SaaS.” Internal tools were expensive to build and maintain. But AI flips the math, meaning all the UI logic and AI setup is now a simple weekend project. What remains is the part you’d want to keep in-house anyway: the security model, the schema, the questions specific to your business.

Data analytics has gone from one of the most time-consuming parts of founder life to one of the most fun. The oracle delivers, just like the Greeks promised.