Natural-language SQL demos usually stop at the happy path.
A user asks a question.
The model writes SQL.
The database returns an answer.
Everyone claps.
Production is less polite.
Users ask broad questions. Schemas drift. Joins explode. A retry doubles the load. A vague prompt turns into a table scan against data nobody meant to expose.
That is why AI database agents need query budgets.
What should be budgeted?
At minimum:
- rows returned
- execution time
- query cost
- joins
- tables/views allowed
- tenant or workspace scope
- retry count
- export size
- write operations
The key is that the limit is enforced by infrastructure, not suggested in a prompt.
Read-only is not enough
A read-only role can still be dangerous.
It can run expensive queries, pull too many rows, join unrelated entities, or reveal data outside the userβs intended context.
Permissions answer:
Is this tool allowed?
Budgets answer:
How far may it go?
Production needs both.
Longer version: AI database query budgets
The practical rule:
If the agent cannot explain which budget allowed the query, the audit trail is already too weak.
Top comments (0)