Hi Product Hunt 👋

Why I built "fastdata":

At most companies, getting a number out of the database still means opening a ticket, waiting for an analyst, getting a query or dashboard back, asking a follow-up, and waiting again. A simple question like "how many customers churned last month?" can take days for a few minutes of work. Meanwhile analysts spend their week on those requests instead of the deeper work they were hired for.

AI already writes good SQL. What it doesn't know is your data: what "active customer" means, which table is the source of truth, whether revenue excludes refunds. 'Fastdata' started as a Custom GPT prototype to test that idea. This is the open-source, one-command version.

How it works:

Your team writes down what it knows about the data (glossary, metric definitions, table notes, verified queries) as Markdown files, or lets fastdata learn draft them from your schema. Then anyone can ask in plain language, in a local web chat or the terminal. A Claude agent reads that knowledge base the way a new analyst reads the handbook, writes read-only SQL, runs it through a connector you control, and answers with the result, its assumptions, the files it relied on, and the exact query. Nothing is guessed silently.

What I cared about:

• Read-only is enforced in code (SQL guard + read-only transactions), on top of a read-only DB role

• Your database credentials stay with your connector, not in fastdata's config

• The model sees a row preview, not your whole table

• No connector? It writes the SQL, you run it anywhere and paste the results back, and it analyzes them

• Works with your existing Claude Code login, so you don't need an API key

Try it in a minute:

"fastdata init demo --demo"

sets up a sample database and knowledge base.

Feedback that would help most

1. A question it got wrong, and what the right answer needed. That shows me what to fix in the agent and in the knowledge base format.

2. What you'd put in a knowledge base for your own data, and which parts felt tedious to write.

3. Which database or warehouse you'd connect first. Today Postgres and SQLite are built in, and anything else works through an MCP SQL server or an HTTP endpoint.

4. If you gave it to a non-technical teammate: did they trust the answer, and what would make them trust it more?

Regards,