Why understanding your schema matters more than the SQL

It's tempting to think the hard part of "ask your database anything" is writing the SQL. It isn't. Generating syntactically valid SQL is the easy part. The hard part is generating SQL that's correct for your data, and the gap between those two is where schema understanding lives.

The same question, two schemas

Take a question as simple as "how many active users do we have?" The right query depends entirely on what "active" means in your database:

-- Schema A: a boolean flag
SELECT count(*) FROM users WHERE is_active = true;

-- Schema B: soft-deletes plus recent activity
SELECT count(*)
FROM users
WHERE deleted_at IS NULL
  AND last_seen_at >= now() - interval '30 days';

Both are valid SQL. Only one is right for your table, and you can't know which without seeing the columns and the conventions baked into them.

What the agent can see before it answers

We index your schema into a snapshot, and we give the agent a few tools to read from it while it works out an answer. It can list the tables, describe a single table's columns and types, and look up how tables relate to each other. So instead of inventing a plausible query in the dark, it explores the real structure first and writes against what's actually there.

That's also where relationships come in. Dronk knows your declared foreign keys, and it infers the obvious ones you didn't declare (a user_id column next to a users table) so a join lands on the right key instead of a guess.

Grounding beats cleverness

A model with no schema context will happily invent a customers table that doesn't exist, or join on a column that was renamed three migrations ago. More reasoning doesn't fix that. More grounding does.

The most reliable way to stop a query from being wrong is to make sure the system understands the data before it writes a word of SQL. Get the schema understanding right and correct SQL mostly follows. Get it wrong and no amount of clever prompting will save you.

This is the unglamorous, foundational work behind every good answer Dronk gives.