Introducing ChatPlotDB: ask your database in plain English

Today we're launching ChatPlotDB: connect PostgreSQL, MySQL, DynamoDB or a spreadsheet, ask a question the way you'd ask a colleague, and get back a table or a chart — along with the SQL that produced it.

It is not a text-to-SQL box. Between your question and the query sits a configuration layer that knows which tables matter, how they join, and what your team's words mean. That layer is the product; the model is a component inside it.

Why we built it

In most companies the person with the question and the person who can write the query are two different people, and the gap between them is measured in days. A number that would change a decision on Tuesday arrives on Friday, by which point the decision has already been made without it.

The obvious fix — hand everyone a SQL editor — has been available for thirty years and almost nobody uses it. The reason is not syntax. It is that a schema is a record of every decision the engineering team has ever made, and none of those decisions were made with your question in mind. Two tables called `users` and `accounts`. A `status` column with seven values, three of which are dead. A `deleted_at` that some queries respect and some don't. Knowing SQL does not tell you any of that.

So the hard part was never translating English into SQL. It was knowing enough about a specific database to translate it correctly, and knowing it consistently enough that the same question asked twice returns the same number.

How a question becomes an answer

Five stages, and you can see all of them. You ask, in the app or from a Slack channel. The agent reads the config to decide which tables are relevant and how they join, and asks you a clarifying question if the metric you named is ambiguous rather than guessing.

If SQL approval is switched on, the generated query is shown to you before it runs, and you can approve it, edit it, or throw it away. The query then executes read-only, and a verification pass checks the result for the silent failures — an inner join that quietly dropped half the rows, a filter that matched nothing — before anything reaches you. What comes back is an interactive table or a chart, which you can pin to a dashboard.

The config is the product

A config records which tables are worth exposing, which joins are real, and what your team's vocabulary maps to, so that “active account” resolves to the same definition every time anybody asks. It is the difference between an answer and a plausible answer.

Nobody wants to hand-author that in YAML, so Config Studio writes it: it introspects your schema, samples what the columns actually hold, decides what belongs, and emits a draft you read in plain language before saving. A config that fails its verification gate is never offered to you at all.

“I spent years watching good decisions wait on a query that took someone else four days to get to. The point of ChatPlotDB is not that it writes SQL — it is that it shows you the SQL it wrote, so the answer is something you can check rather than something you have to trust.”

What you can connect

PostgreSQL and MySQL with credentials encrypted at rest and the usual SSL modes. Amazon DynamoDB, with items flattened into tables you can query. CSV and Excel files, uploaded and queried directly with no approval step, because there is no database to protect. And two to five of those at once: a stitched config composes several connections into one conversation, so a question can cross the line between your billing data and your product data without anybody exporting anything.

ChatPlotDB is available now, with a free tier. Point it at the sample database and you can have a real answer back before you have connected anything of your own.