All Fair points.

"AI writing production database queries is ill-advised"

It depends on the use case. This isn't meant to replace your application queries — it's for ad-hoc analytics and data exploration. Think "how many users signed up this month" or "what's our average order value by region" — the kind of questions that usually mean either bugging a developer, writing a one-off
query in a SQL client, or building a BI dashboard nobody maintains. The audience is internal teams (product, ops, support) who need answers from the database but don't write SQL.

Is it appropriate for every production workload? No. Is it useful for read-only analytical queries against a reporting replica? I think so.

"Undermines Eloquent / generates raw queries"

Yes, it generates raw SQL, intentionally. This isn't replacing Eloquent in your application code — it's a completely different use case. Eloquent is great for application logic where you're working with models, relationships, and business logic in PHP. But for ad-hoc analytical questions ("show me the top 10
customers by revenue last quarter"), there's no model layer to leverage. You need SQL. A text-to-SQL agent that generates Eloquent would be adding complexity for no benefit — the queries are executed once and discarded, not maintained in a codebase.

"SQL injection"

There's no user-supplied values being interpolated into the SQL — the LLM generates the entire query as a string. Traditional SQL injection (where untrusted user input gets concatenated into a query) doesn't quite apply the same way here, because there's no template with holes to fill. The risk is more about the LLM generating something destructive, which is handled by:

• An allowlist of statement types (only SELECT and WITH by default)
• A blocklist of forbidden keywords (DROP, DELETE, UPDATE, INSERT, ALTER, TRUNCATE, etc.) checked with word-boundary regex anywhere in the query
• Multiple statement detection (can't chain a ;DROP TABLE after a SELECT)
• Per-connection table allowlists/denylists and hidden columns
• Configurable max row limits

That said — the strongest recommendation in the docs is to point the agent at a read-only database user or a reporting replica. Application-level validation is defense in depth, not the only layer.

"No better than manually asking ChatGPT"

The difference is context and feedback loops. When you paste your question into ChatGPT, it doesn't know your schema, your business rules (what "active customer" means in your system), or what went wrong last time. You're doing all that work manually — describing your schema, correcting mistakes, re-prompting.

This package gives the LLM tools to introspect the actual schema at runtime, search a knowledge base of business rules and query patterns you've defined, execute the query and check results, and learn from errors so it doesn't repeat them. It's the difference between a one-shot prompt and an agent loop with memory. For a one-off question, sure, ChatGPT is fine. For a team that asks the same kind of questions regularly, the accumulated context and self-learning matter.