From Question to Query: Building an AI Database Assistant

Ever wished you could just ask your database a question — in plain English — and get a real answer back? No SQL, no waiting on the data team. That's the whole promise of Natural Language to SQL (NL2SQL for short), and thanks to LLMs, it finally works well enough to be useful.

But here's the part most people get wrong: getting an AI to write SQL is the easy bit. The magic is in everything that happens around it. In this article we'll build the whole picture together, one piece at a time.

What we're building

We're going to trace the full journey of a single question. Here's what the AI has to do, in order:
• Read the database — what tables and columns are even in here?
• Find what matters — pick the few tables that relate to the question
• Write the SQL — turn your words into a query
• Check it's safe — before it ever touches the database
• Run it — and hand back the answer

Miss any one of these and the whole thing gets flaky. So all five matter — and we'll see why as we go. Let’s walk each stop.

Step 1: Get to know the database

The AI can't answer anything until it knows what it's working with. So first it takes a look around — a process called schema introspection.
The good news: databases can describe themselves. Most expose their blueprint through a built-in view called information_schema, so we just ask:

But names alone can be cryptic. What does a column called rev mean? Is status 2 good or bad? So the AI also grabs little hints — descriptions, comments, and a few sample values — to make sense of it all. Then it caches this map, because rebuilding it on every question would be painfully slow.

Step 2: Zoom in on what matters

Here's a trap: real databases can have hundreds of tables. It's tempting to just dump them all into the prompt and let the AI figure it out. Don't. LLMs have a limited context window (how much text they can read at once), and stuffing it with junk actually makes the AI worse — the useful tables get lost in the noise. It's expensive, too.
Instead, we hand the AI only the tables it needs, using semantic search:

1. Ahead of time, turn every table description into an **embedding **and store it in a vector database.
2. When a question arrives, embed it too and search for the closest-matching tables.
3. Pull in any connected tables (via foreign keys) so joins still work.
4. Add business definitions — like what "active user" or "revenue" means in your company. This step is the unsung hero. It's what keeps the SQL accurate and the bill small, even when the database is huge.

Step 3: Let the AI write the SQL

Now the fun part. We build a *prompt *— the instructions we send the model — with everything it needs: a few ground rules (which SQL flavor, keep it read-only, no SELECT *), the tables we picked, a couple of examples, and finally the question.

That trick of showing a couple of example question-and-SQL pairs has a name: few-shot prompting. And it works surprisingly well — a few good examples teach the model how your database likes to be queried far better than a wall of instructions.

Step 4: Never trust, always check

Rule number one: don't run whatever the AI spits out. LLMs sometimes hallucinate — they invent a table or column that doesn't exist, or write something risky. So every query goes through a safety gate first. We parse it (read its structure with a tool like sqlglot) to confirm it's valid and a single statement, confirm it's read-only, and check that the tables and columns are real.

See that last line? EXPLAIN asks the database to plan the query without actually running it — a cheap way to catch mistakes before a single row is read. Only once everything passes do we run it for real, on a read-only connection with a row cap and a timeout, so nothing can go rogue. Whatever comes back is the answer your user sees.

Wrapping up

Here’s the thing I hope sticks with you: the AI writing the SQL isn’t the clever part. That’s just the last little step. The real work — the stuff that makes it actually trustworthy — is everything happening quietly in the background.
Think of the AI like a really good translator at a busy restaurant. It only does its job well because it already knows the menu (your schema), it listens for what you actually want instead of everything on the wall (the right context), and it double-checks the order before it hits the kitchen (validation). Skip any of those and you get the wrong dish — fast, confidently, and completely wrong.
But get them right, and something kind of magical happens. The person asking doesn’t need to know SQL. They don’t need to file a ticket. They don’t need to wait on anyone. They just… ask — and a real answer comes back. That’s the whole dream, and it’s a lot closer than it used to be.

*So next time someone says “the AI just writes the query,” you’ll know the truth: the query is easy. Everything around it is where the magic lives.
*