# AI Data Analyst: every question answered from your own database, built at $0

An AI data analyst is a model that answers business questions by writing and running SQL against your own database, then returning the number with the query it used. Most of them are unreliable for one reason: the model guesses at column names it has never read. Axionry builds one that cannot. It is blocked from executing SQL against any table whose schema it has not just inspected, enforced by a signed token rather than a line in a prompt. It runs inside your own infrastructure against a read-only replica, so your database credentials never leave your network.

## What is an AI data analyst?

It is not a chatbot bolted onto a dashboard. It takes a question in plain English, finds the right tables, writes the SQL, runs it against a read-only copy of your database, and hands back the answer with the query attached so anyone can check it.

The people who need one are the people currently waiting. Every company has a queue of questions sitting in front of the one or two engineers who can write SQL. How many trial users from the June cohort converted is fifteen minutes of work and a three-day wait for whoever asked. The wait is the cost, not the fifteen minutes.

## Why do text to sql tools get the answer wrong?

Because the model is allowed to guess. Most text to sql products paste a schema dump into the prompt and hope it gets read. On a large schema the dump is truncated, and the model fills the gap with a column name that sounds plausible. It asks for a signup date column that does not exist, the query fails, it tries again, and eventually it lands on something that runs. A query that runs is not a query that is right.

The second failure is quieter and worse. The join is valid SQL and returns a believable number from the wrong relationship. Almost every production database has a legacy column kept for backward compatibility, and anybody who was not told will keep joining on it for years. Nobody notices, because the number looks like a number.

Neither problem is solved by a better model. They are solved by not letting the model near the query until it has read the schema.

## How does natural language to SQL stay correct on a real schema?

By removing the ability to guess rather than asking politely. The build runs a three-stage sequence. Stage one returns your business context and a short-lived signed token. Stage two takes that token and returns the exact table definitions for the tables named, issuing a second token scoped to each individual table. Stage three refuses to execute anything unless it is handed a valid token for a table in that query, and the tokens expire after fifteen minutes.

The effect is easy to state. The model physically cannot run a query against a table whose schema it has not just read. That is not an instruction it might ignore under pressure. It is a signature check in code, and it fails closed.

Result size is capped too, which sounds like a limit and works as a correctness feature. A query returning more than a few kilobytes is rejected, so the aggregation has to happen in SQL where it is verifiable, rather than the model pulling ten thousand rows and doing arithmetic on them out of sight.

## Where does it run, and who holds the database credentials?

Inside your infrastructure. The service is deployed in your own cloud account, pointed at a read-only replica you create, using a role your team grants. We never hold a credential to your database. In practice that is the sentence that ends a security review rather than starting one.

The role matters more than most teams expect. A blanket read-only grant can read every column in the database, including compensation, contact details and anything regulated. So part of the engagement is writing the grant list: the specific tables and columns the analyst may see, approved by whoever owns data protection at your company, and nothing outside it. A question about data that is not on the list fails at the database rather than being caught by a filter somewhere upstream.

Every question is logged with the SQL it generated, the tables it touched, how long it took and whether it errored. When somebody asks where a number came from, the answer is a row in a table rather than a memory.

## What does the semantic layer actually contain?

The part that makes answers correct rather than merely valid. A schema tells the model that a column exists. It does not tell it which filter your company means by a free-tier user, or that two tables describe colleges and only one of them is the source of truth, or that a name field on a legacy table has meant nothing since 2024.

So the engagement writes that down: your glossary in your own words, the joins that are correct as against the joins that merely run, the filter behind each business term, and the tables to ignore entirely. Every company's version is different, which is exactly why this is an engagement and not a signup form. It is also where the accuracy comes from, so it is the part that gets the most attention.

## How is this different from a BI tool or an AI analytics tool?

A dashboard answers the question somebody already anticipated. This answers the ones nobody did, which is most of them, and it answers them in the ninety seconds before the person gives up and guesses instead.

A vendor AI analytics tool wants your data in their cloud, or at the very least your credentials in their vault. This runs in yours, and the difference shows up the first time your largest customer sends a security questionnaire.

It also connects to the assistant your team already pays for. The analyst is exposed over MCP, so it appears as a tool inside Claude or ChatGPT in your organisation's workspace, behind your existing Google sign in. Nobody has to learn a new interface or remember another password, which is usually the difference between a tool that gets used and one that gets demoed once.

## Can it query several databases at once, including different types?

Yes, and that is usually the reason a team calls in the first place. PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Amazon Aurora and CockroachDB on the relational side. Snowflake, BigQuery, Amazon Redshift, Databricks and ClickHouse for the warehouse layer. MongoDB, Cassandra, ScyllaDB, DynamoDB and Elasticsearch where the events and documents ended up.

They get federated into one queryable surface, so a join between a table in Postgres and a table in ClickHouse is a single statement rather than two exports and a lost afternoon. Where the databases sit in different VPCs or different cloud accounts, a private read path is built between them, peered or through a private endpoint, and neither database is ever exposed to the internet.

Spreadsheets, CSV exports and Parquet files sitting in a bucket are registered as tables alongside the real ones. That is the part teams assume they need a data lake for, and it is very often the part holding the number they actually wanted. Structured and unstructured, queried together, without buying a lake or hiring somebody to run it.

## Can the whole pipeline run on a private LLM instead?

Yes, and for some buyers it is the only version that ever gets approved. In the default deployment the only things that leave your network are the question text and the table definitions. The rows never do: the SQL executes inside your infrastructure and the result set is rendered there. For a lot of teams that is already inside policy, and it is worth checking before assuming otherwise.

Where it is not, the entire pipeline moves onto a model running on hardware you own. vLLM serving on your own GPU or a dedicated instance in your own cloud account, the analyst reaching it over a private network path with no public exposure, and nothing at all crossing your perimeter. Not the question, not the schema, not the answer. A fully air-gapped deployment with no outbound network access is supported too.

This is the same private LLM infrastructure work Axionry already does as a standalone engagement, so it is a configuration of this build rather than a second project with a second bill. Regulated healthcare, financial services and public-sector teams usually start here instead of arriving at it after a failed security review.

## Can it find correlations nobody thought to look for?

This is where a single setup pays for itself the second time. Once the databases are federated and the glossary is written, the useful questions stop being the ones somebody planned a chart for. Which acquisition channel produces users still active in month six. Whether support volume moves ahead of churn or behind it. Which onboarding variant correlates with a second purchase rather than a first.

None of those have a dashboard, because nobody knew to build one, and they are usually the questions that move revenue. The analyst can hold both sides at once because both sides now live on the same surface. It writes the query, runs it, and shows you the SQL, so your team argues with the method rather than trusting a number on faith.

What it will not do is tell you a correlation is a cause. It returns the relationship and the query that found it. The judgement stays with your people, which is the correct place for it.

## What does this actually replace?

The queue, first. Every company has two or three people who can write SQL, and a line of colleagues waiting on them. Those engineers stop being a help desk and go back to building, which is usually worth more than the analytics itself.

Then the seat sprawl. Most business intelligence licences are paid for people who open the tool twice a quarter, and the seat exists only because that person occasionally needs an answer. That is precisely the use case that should never have needed a seat.

It does not replace your dashboards, and it should not try to. Standing numbers belong on a chart somebody designed deliberately. What changes is everything that is not a standing number, which in most companies is the large majority of what actually gets asked.

## Has this been built before, or would we be the first?

It runs in production at AccioJob, where Neeraj is head of engineering. Two Postgres databases, the full table definitions for both held in the knowledge base, and cross-database joins handled through Postgres foreign data wrappers so a single question can span both products in one statement.

The proof chain, the grant scoping and the audit log described on this page are the ones in that system. They are not a design sketch waiting for a first client to fund them.

## Pricing

| Stage | What happens | Timeline |
| --- | --- | --- |
| Assessment | Read-only access to one replica. Schema inventoried, the questions your team actually asks classified as answerable or not, the grant list drafted with your data owner, and acceptance criteria written as testable statements | Five business days from access |
| Build | Deployed in your cloud account, connected to your replica and to your Claude or ChatGPT workspace, with the semantic layer written for the first domain. Delivered as separately accepted checkpoints, each invoiced only after you accept it | About three weeks |
| Upkeep, optional | The semantic layer maintained as your schema moves, further domains added, and the generated queries reviewed each month | Monthly, cancel any time |

Builds start at $2,500 and most land between $2,500 and $6,000, set by how many databases are in scope and how much of the schema the first domain has to cover. Optional upkeep from $1,200 a month. The assessment is a fixed fee credited in full against the build, and nothing is payable before a checkpoint is delivered and accepted. Thirty days of defect correction is included.

## FAQ

### Can it ever run an UPDATE or a DELETE?

No. It connects to a read-only replica through a role with no write privilege, so a write is refused by Postgres itself rather than by a rule the model has been asked to follow. The replica is yours and you create it.

### Does our data or our schema leave the network?

The rows never do. SQL executes inside your infrastructure and the result is rendered there. By default the question text and the table definitions are sent to a hosted model, and where even that is not acceptable the whole pipeline runs on a private LLM on hardware you own, including fully air-gapped with no outbound access at all.

### How many tables can it handle?

The production system this is based on carries the full definitions for two databases at once. Table count is not the constraint. The real constraint is how many of those tables carry business meaning that has never been written down anywhere, which is precisely what the assessment measures.

### Does it work on something other than Postgres?

Postgres is where it is proven. MySQL, SQL Server, Snowflake and BigQuery are the same shape of work and the schema layer is adapted rather than rewritten. Ask on the call and you will be told plainly which of those is a port and which is closer to a rebuild.

### Do we need Claude or ChatGPT for this?

You need one of them on a paid organisation plan, because that is where your team will actually ask the questions. Sign in runs through your existing Google workspace over OAuth, so there is no new account to manage. If you would rather it sat behind your own interface instead, that is buildable and costs more.

### What stops somebody asking for data they should not see?

The grant list. The role the analyst uses can only read the tables and columns your data owner approved, so an out-of-scope question fails at the database. Row-level security is available where a team needs per-user scoping on top of that.

### Who owns it when the engagement ends?

You do. It runs in your cloud account, the code and the semantic layer ship into your repository, and all our access is removed at handover with written confirmation. It is deliberately written to be readable, so your own engineers can extend it without us.

### How can you price this before seeing our schema?

That is what the assessment is for, and why it is a fixed fee credited in full against the build. Nobody can responsibly quote a semantic layer without reading the schema first. A fixed quote given before that is a guess, and you are the one who ends up paying for it.

### How much does an AI data analyst cost?

Builds start at $2,500 and most land between $2,500 and $6,000, depending on how many databases are in scope and how much of the schema the first domain covers. Optional upkeep starts at $1,200 a month. The assessment is a fixed fee credited in full against the build, and nothing is payable before a checkpoint is delivered and accepted.

### How long does it take to set up an AI data analyst?

Five business days for the assessment, counted from when read-only access to one replica is granted, then about three weeks for the build. The build covers deployment in your cloud account, connection to your replica and to your Claude or ChatGPT workspace, and the semantic layer for the first domain, delivered as separately accepted checkpoints.

### How accurate is text to SQL on a real production schema?

Accuracy depends on stopping the model from guessing. Here it cannot execute SQL against a table whose schema it has not just read, enforced by signed tokens that expire after fifteen minutes. Large result sets are rejected, so aggregation happens in verifiable SQL. A written semantic layer supplies the correct joins and business filters, which is where most of the accuracy comes from.

### Can one question join data from Postgres and a data warehouse?

Yes. Databases are federated into one queryable surface, so a join between a table in Postgres and a table in ClickHouse is a single statement. Where databases sit in different VPCs or cloud accounts, a private read path is built between them, and neither is exposed to the internet. Spreadsheets, CSV exports and Parquet files in a bucket can be registered as tables too.

### Will an AI data analyst replace our BI dashboards?

No, and it should not try to. Standing numbers belong on a dashboard someone designed deliberately. The analyst handles the questions nobody built a chart for, which is most of what gets asked. What it does replace is the queue in front of the engineers who write SQL, and many of the BI seats paid for people who need an answer twice a quarter.

### How can we check where a number came from?

Every answer comes back with the SQL that produced it, so anyone can read the method. Every question is also logged with the generated query, the tables it touched, how long it took and whether it errored. When someone asks months later where a figure came from, the answer is a row in a table instead of somebody's memory.

### What happens when our database schema changes?

The optional upkeep plan, from $1,200 a month and cancellable any time, keeps the semantic layer current as your schema moves, adds further domains and reviews the generated queries each month. Without upkeep, the code and semantic layer live in your repository and are written to be readable, so your own engineers can update them.

### Do we pay anything before the AI data analyst is built?

Nothing is payable before a checkpoint is delivered and accepted. The assessment is a fixed fee, credited in full against the build, and the build itself arrives as separately accepted checkpoints, each invoiced only after you accept it. Thirty days of defect correction is included after delivery, so issues found in early use are fixed without a new engagement.

*Last updated: 2026-09-22*
---

HTML version: https://axionry.com/services/ai-data-analyst

Axionry is an AI product development and cloud cost optimization studio founded by Neeraj Sharma. Contact: neeraj@axionry.com. Book a call: https://axionry.com/book