MySQL
Chat with your MySQL database
Ask your application's database a question in English. ChatPlotDB works out which tables matter and how they join, writes the SQL, runs it read-only, and returns a table or a chart.
ChatPlotDB is an AI data analyst for MySQL. It connects with a host, port, database, user and password over the SSL mode your server requires, and answers questions against the schema you already have, including the one that grew under an application over eight years and was never documented.
The questions the app'sown database can answer
Order volume, refunds, repeat customers, cohort behaviour: the numbers already sitting in your production tables.
“What were total orders and revenue by week this quarter?”
“Which products were refunded most often in the last 90 days?”
“How many customers have ordered more than twice?”
“What's the average order value by acquisition channel?”
“Which regions grew fastest month over month this year?”
“How many active users did we have each week since January?”
It reads the schemayou inherited
Nobody designs the database they end up with. Columns get abbreviated, flags get reused, and the person who knew why has left.
Your words, not the column names
The config layer records what your team means by "active customer" or "churned", so the same phrase resolves the same way every time, for everyone who asks.
Joins nobody remembers
Which table links orders to refunds, and through what? The config knows, so a question spanning four tables becomes one correct query instead of a support ticket.
Read-only, always
Only read queries are ever issued. Connect it with a MySQL user that has SELECT and nothing else, and the credential itself cannot change a row.
Ambiguity gets a question, not a guess
If the metric you named could mean two things, the agent asks which you meant before querying, rather than returning a confident, wrong number.
The query is there to check
Every answer arrives with the SQL that produced it, so an empty table caused by a bad join can be spotted for what it is rather than read as a real zero.
Answers that stay answered
Save a result as a dashboard card, refresh it on a schedule, and get pinged in Slack when the number crosses a threshold you set.
Why this isn'ta text-to-SQL box
A model that sees only your schema will guess at your business. The gap between those two things is where wrong answers come from.
Point any language model at a raw MySQL schema and ask for last quarter's revenue, and it will write something plausible. Whether it is correct depends on questions the schema cannot answer: does revenue mean gross or net of refunds, does an order in status 7 count, is deleted_at NULL the only definition of a live record?
ChatPlotDB puts a configuration layer between your question and the query. It records which tables matter, how they join, and what your team's vocabulary means, so "active account" resolves identically whether it was the finance lead or a new hire who asked. Config Studio generates that layer from your schema, and you correct it once rather than correcting every answer forever.
The practical effect on an old schema is large. A column called flg_1 means nothing to a model reading it cold; once it is described in the config as the refund flag, every future question that touches refunds is right. That is the difference between a demo that works on a clean schema and something a team can rely on against a real one.
Common questions
That is the case it is built for. Config Studio reads your schema and generates a configuration layer describing which tables matter, how they join, and what the columns actually represent. You correct that description once, and every question afterwards benefits.
The agent plans against the config rather than reading raw column names cold, which is why it copes with a schema that grew rather than one that was designed.
No. Only read queries are ever issued, and the recommended setup is a dedicated MySQL user granted SELECT on the tables you want queried and nothing else.
Yes. A connection is a host, port, database, user and password, so any MySQL endpoint you can reach will do, and a replica is a sensible choice if you'd rather analytical queries never touched the instance serving your application.
That's the point. Questions are asked in plain English and the SQL is generated for you. The query is shown alongside the answer, so the people who read SQL can check it and the people who don't never have to look.
The config records the join paths, so a question touching orders, customers, and refunds becomes a single query rather than three partial ones you'd have to reconcile by hand.
If the question is genuinely ambiguous, the agent asks a clarifying question first instead of picking an interpretation silently.
Yes. A stitched config composes between two and five databases into one conversation, so a question can span your MySQL and whatever sits beside it without an export step.
